https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#Overall-Options

https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/C-Dialect-Options.html#C-Dialect-Options

Utilisation classique :

g++ fichier.cpp -std=c++11 -Wall -Wextra -o fichier_executable

-o fichier_executable

-o pour output, permet de définir le fichier de sortie. Si absent, le fichier créé est nommé a.out

Détermine le langage standard:

-std=c++14

Compilation simple (sans assemblage) :

Configuration

Pour commencer, travaillant essentiellement sous GNU/Linux (Ubuntu), les fichiers doivent être codés en UTF-8. Pour définir cela dans Eclipse :

Window -> Preferences -> General -> Workspace : Text file encoding, UTF-8 et mes accents sont correctement affichés

Oui mais les mots français sont marqué mal orthographiés, oups, eclipse is not french native !-)

http://www.eclipse.org/babel/downloads.php

Une ressource précieuse:

Politique de contribution open source de l'État

miniature du schéma d'Oliver Steele

Comme beaucoup, j'ai utilisé git pendant des années sans utiliser l'index. C'est alors qu'un collègue se met à git et me parle de l'index… pas clair!

Et le hasard faisant bien les choses, arrive un cours Git avancé de Matthieu Moy, dont la page 21 reprend ce graphe très clair d'Oliver Steele dans sa page My Git Workflow:

horloge du dôme de Florence (src: https://commons.wikimedia.org/wiki/User:Watchduck)

La date est incontournable,

le sysadmin (ASR) a parfois besoin:

Et on monte encore d'un cran : git sur mon serveur local :

Actuellement, on privilégiera plutôt une implémentation de gitlab community editions (ce)

Que ce soit pour la remontée de bugs, assurer la compatibilité entre machine ou simplement s'assurer que l'on dispose d'une version à jour, il est souvent indispensable qu'un logiciel contienne un numéro de version. Il peut-être géré de multiples façons. Si vous ne l'avez pas déja lu, je vous invite à lire l'article sur la "Gestion sémantique de version" en copie ci-dessous

Premier pas

Afin d'avoir un fichier VERSION qui contient le numéro de version du programme, j'avais créé tout d'abord un script tag.sh avec:

J'ai travaillé (essentiellement seul, avec serveur locale) durant des année et n'ai pas resenti le besoin d'avoir recourt à git rebase

Ça y est, ce temps est révolu. Même si je suis sur un projet où je travaille seul, j'en ressens le besoin:

Je travaille avec Symfony et je suis en train de créer des entités (classe associée à une table de base de données). J'ai commencé à créer une entité (table) importante (Sample pour des échantillons archéologiques) qui utilise des relations (Join) avec d'autres. Ce travail se fait dans la branche feature/entity/sample

Bien que mon schéma de base soit globalement défini, je décide de le changer. J'arrête donc la création de Sample et créer l'entité (table) manquante: SamplingMode (mode de prélèvement de l'échantillon). J'ai donc remisé le travail en cours sur ma branche feature/entity/sample, je reviens à ma branche develop et je crée une nouvelle branche feature/entity/sampling_mode, crée cette entité, commit, revient sur develop et merge.

Je reviens donc sur ma branche feature/entity/sample, récupère mon travail en cours (stash pop) pour continuer… oui mais mon entité SamplingMode n'existe pas! Il faut donc que je rebase cette branche sur ma branche principale develop pour récupérer les modifications faites juste avant.

git rebase develop

et voilà un petit alt-r dans Vim et mon fichier d'entité pour sampling_mode apparaît, je créer la relation entre sample et sampling_mode