AVERTISSEMENT: cet article a été écrit il y a plus de 10 ans. Les bases sont les mêmes, mais, par exemple, les éditeurs graphiques ont évolué (Eclipse, ou plus minimalement, gedit), ou encore, l’utilisation de Git pour la gestion des révisions.

Version 1.3 (2001/09/12) Auteur: Mathieu Lutfy (mathieu@bidon.ca)

1.0 Introduction
   1.1 Préambule
   1.2 Redistribution
   1.3 Conventions utilisées dans ce texte
   1.4 Pourquoi programmer sous Linux ou Unix?
   1.5 La guerre des éditeurs
2.0 Survol des éditeurs graphiques
   2.1 Note
   2.2 Code Crusader
   2.3 KDevelop
   2.4 jEdit
   2.5 NEdit
3.0 Survol des éditeurs traditionnels
   3.1 Introduction
   3.1 Emacs / XEmacs
   3.2 Vi / Vim / gVim
4.0 Compiler
   4.1 gcc
   4.2 make
5.0 Déboguer
   5.1 gdb
   5.2 lclint
6.0 Migrer de Windows vers Linux/Unix
   6.1 Transfers de fichiers
   6.2 Votre code est-il portable?
7.0 Conclusion
8.0 Références
9.0 Remerciements

1.0 Introduction

1.1 Préambule

Ce texte vise à donner une introduction générale aux ressources disponibles pour la programmation sous Linux. Ce texte prend pour acquis que le lecteur est familier avec les bases de la programmation, que ce soit sous MS Windows ou MacOS.

Vos commentaires ou corrections sont les bienvenues à mathieu@bidon.ca. Vous pouvez retrouver la version originale et les versions futures de ce texte à l’adresse suivante: http://mtl2600.dhs.org/textes/intro_prog_linux.txt

1.2 Redistribution

Vous pouvez librement redistribuer ce texte, en autant les termes de la “GNU Free Documentation License” soient respectés:

Copyright (c) Mathieu Lutfy (mathieu@bidon.ca) Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts.

Plus d’information sur la licence: http://www.gnu.org/licenses/fdl.txt

1.3 Conventions utilisées dans ce texte

  • Les références sont à la toute fin du texte. Lorsqu’une de ces références sera mentionnée dans le texte, il y aura un chiffre (ex: [1]) indiquant le numéro de la référence en question.

  • Les sites web des applications mentionnées dans ce texte sont joints aux références (à la fin du texte).

  • Ce texte fait spécifiquement référence à Linux, mais la majorité des pricipes s’appliquent à Unix en général (FreeBSD, OpenBSD, SunOS/Solaris, etc..).

  • Le signe $ en début de ligne représente l’invite de la ligne de commande (prompt) et ne doit pas être inclu dans la commande comme tel.

1.4 Pourquoi programmer sous Linux ou Unix?

Linux est un système d’exploitation multi-plateforme (IA32, IA64, PowerPC, Alpha, Sparc, etc..) à la fois flexible, stable et performant. De plus, Linux a été architecturé avec la même philosophie qu’Unix et il existe un standard de programmation nommé POSIX (Portable Operating System Standart) qui permet aux programmeurs de conserver un niveau d’abstraction suffisamment élevé face aux différents systèmes d’exploitation.

Le plus grand avantage découle probablement du fait que la philosophie dominante des usagers de Linux est celle du Logiciel Libre (Free Software). L’usager est donc libre d’adapter un programme à ses besoins, libre de participer au développement du logiciel et libre de copier le code source d’une application dans son application, en autant que les deux applications soient considérées des Logiciels Libres.

Pour plus d’information sur la philosophie Unix, voir “The Art of Unix Programming”[1], par Eric S. Raymond. Les détails sur la philosophie du Logiciel Libre est disponible sur le site de GNU[2].

1.5 La guerre des éditeurs

Une bonne partie de ce document est consacrée aux éditeurs pour programmer. La raison est très simple, sous Linux, les gens sont généralement d’accord pour dire que GNU gcc est le meilleur compilateur, GNU gdb un excellent débogueur, etc.. mais étant donné que les usagers passent la majorité de leur temps à programmer dans un éditeur de texte, ils tendent à être très pointilleux sur le comportement de ce dernier.

De plus, il y a deux types d’éditeurs: les IDE (Integrated Development Environment) et les programmes qui ne sont qu’un éditeur de texte. Les usagers de MS Windows sont probablement familiers avec l’IDE “MS Visual C++”, et les éditeurs “simples” tels que Notepad ou Ultra Edit.

De façon générale, les IDE ont une interface graphique au compilateur et au débogueur, tandis que l’éditeur ne fait qu’éditer et a une interaction limitée avec le compilateur et le débogueur (c’est le cas pour tous les éditeurs mentionnés dans cet article).

Sous Linux, il n’y a pas un éditeur prédominant. Vi/Vim, Emacs, Code Crusador, KDevelop, NEdit, jEdit, etc.. ne sont que le début de la liste. De plus, le débat cherchant à définir “le meileur éditeur” est toujours d’actualité. À chaque année, des partisans de Vi et Emacs (deux vétérans dans le domaine de la programmation) se réunissent pour s’affronter dans une partie de “paintball”.

2.0 Survol des éditeurs graphiques

2.1 Note

Trois points communs sont dans les sections ci-bas: sous-applications supportées, langages/syntaxes supportés et licence. J’ai eu de la difficulté à choisir une expression qui s’appliquait à tous les éditeurs concernant les deux premières sections. Je m’explique:

  • Sous-applications supportées:

La majorité des IDE n’ont pas de compilateur ou débogueur intégré (tel qu’expliqué dans la section 1.5), mais auront une interface graphique pour simplifier la sortie texte des applications appelées, donnant l’impression que le compilateur est intégré. Une sous-application qui n’est pas listée signifie que pour l’exécuter, il faudra lancer la commande par un terminal. Beaucoup d’éditeurs font cela parce que leurs usagers préfèrent utiliser ces outils de la façon traditionnelle (et standard) plutôt que d’avoir une interface différente pour chaque éditeur.

  • Langages/syntaxes supportés:

Ceci signifie que l’éditeur est capable de surligner et indenter le code. Si votre langage préféré n’est pas listé, cela signifie que l’éditeur agira comme un éditeur de texte ordinaire (à-la-Notepad), mais certaines fonctionalités seront quand même configurables.

  • Licence:

Tous les logiciels dans ce texte sont des Logiciels Libres, c’est à dire que vous avez accès à leur code source et leur utilisation n’est pas limitée. Vous trouverez plus d’information sur les différentes licences “Libres” sur le site de GNU[2] et OpenSource[3] (ils ont des mentalitées divergentes, mais pour vous l’usager, ils sont équivalents).

2.2 Code Crusader

Inspiré par l’interface graphique de Metrowerks Code Warrior, Code Crusador est probablement un des éditeurs qui inclue le plus d’outils graphiques pour programmer, dont un débogueur graphique (Code Medic), un générateur de graphique pour illustrer graphiquement l’héritage des classes C++ et génère automatique les fichiers Makefile (pour automatiser la compilation), en plus des fonctionalités habituelles, soient la vérification et colorisation du code source, etc..

Le seul défaut à cette application pourrait être un peu irritant. L’application a été écrite avec un API graphique nommé “JX Application Framework”, dont l’apparence est loin d’être aussi attrayante que celles de GTK+/Gnome ou QT/KDE. Par contre, l’application est très rapide et ne consomme pas beaucoup de mémoire vive.

  • Sous-applications supportées: Fortran, bison, cc, CC, flex, gcc, g++, g77, KAI C++, make

  • Langages/syntaxes supportés: C, C++, HTML (voir leur site web pour plus d’informations, beaucoup d’autres langages sont partiellement supportés)

  • Licence: New Planet Software Library Open Source License Version 1.0 (basée sur QPL)

2.3 KDevelop

Fortement inspiré de Microsoft Visual C++, KDevelop mise sur la facilité d’utilisation et outils d’aide à la programmation. Parmis ses points forts sont le support des projets QT/KDE et GTK+/Gnome, un navigateur visuel de classes (C++), une interface à CVS (Control Version System) et un assistant de projets (app wizard + générateur de fichiers autoconf/automake).

Leur site web contient une impressionnante quantité d’information, tutoriels, forum de discussion, etc. Chose rare pour un éditeur de programmation. Petit inconvénient, l’éditeur comprend que les langages C et C++.

  • Sous-applications supportées: autoconf, automake, make, gcc, g++
  • Langages/syntaxes supportés: C, C++
  • Licence: GNU GPL

2.4 jEdit

jEdit se veut simple, flexible et pratique. Plus de 40 langages sont supportés, indentation automatique, vérification de syntaxe et transferts FTP intégrés (donne l’impression d’éditer un fichier à distance) ne sont que quelques fonctionalités, mais son architecture modulaire très flexible est très intéressante. Lancez le gestionnaire de “plugins” lorsque vous êtes connectés à Internet et celui-ci ira chercher la liste des plugins disponibles et les téléchargera au besoin. De plus, le navigateur de classes rend la programmation Java et C++ plus agréable.

L’application est écrite en Java, ce qui, comme toutes applications Java, est un avantage et un inconvénient. D’une part, il est un peu plus lent et un peu gourmand, mais en revanche, vous pourrez l’utiliser sur toutes les plateformes supportées par Java (Unix, MacOS, Windows, etc..).

  • Sous-applications supportées: Aucune, mais des plugins supportent le Java
  • Langages/syntaxes supportés: Java, C, C++, Perl et plus de 40 autres
  • Licence: GNU GPL

2.5 NEdit

NEdit est petit et facile à configurer. Son apparence est très minimaliste, mais il peut surligner du code, faire des macros et beaucoup plus que les autres éditeurs de cette catégorie. Toutefois, il ne gère pas les projets et il n’a pas d’interface graphique à la compilation.

  • Sous-applications supportées: aucune
  • Langages/syntaxes supportés: Ada, C, C++, Fortran, Java, Perl, Python et beaucoup d’autres
  • Licence: GNU GPL

3.0 Survol des éditeurs traditionnels

3.1 Introduction

Les deux principaux éditeurs traditionnels sont Vi et Emacs. Connus par certains comme étant inutilement complexes, mais aussi connus pour leur flexibilité et efficacité.

3.1 Emacs / XEmacs

Emacs contient beaucoup trop d’outils et de commandes pour en faire un survol dans ce texte. Par contre, c’est facile de se promener dans l’éditeur avec les quelques commandes suivantes:

(N.B. Ctrl est représenté par “C” et la virgule “,” devrait se lire “suivi de”)

C-x, C-f : Ouvrir un fichier (la touche Tab peut être utilisée pour compléter  ou lister les choix disponibles)
C-x, C-s : Sauver un fichier
C-s      : (search) Faire une recherche dans le texte
C-g      : Annuler la commande en cours
C-x u    : (undo)  Annuler la dernière commande
C-x 2    : Créer une nouvelle fenêtre horizontalement
C-x 3    : Créer une nouvelle fenêtre verticalement
C-x 1    : Cacher les autres fenêtres et affiche que la fenêtre active
C-x o    : Se déplacer d'une fenêtre à l'autre (comme Alt-Tab dans Windows)
C-x k    : (kill) Fermer le texte de la fenêtre active
C-espace : Commencer la sélection d'une région (puis se déplacer avec les
          flèches pour sélectionner une région)
Alt-w    : Copier la région sélectionnée
C-w      : Couper la région sélectionnée
C-y      : Coller la région copiée
C-x, C-c : Quitter emacs

XEmacs est un clône d’Emacs, mais avec une interface graphique plus facile à utiliser. Toutefois, les dialogues de sélections d’XEmacs ont un défaut, pour sélectionner il faut utiliser le bouton du milieu de votre souris et non le bouton gauche (si vous n’avez que deux boutons, il faut cliquer les deux en même temps pour simuler le 3e bouton).

3.2 Vi / Vim / gVim

Vi est un éditeur très minimaliste, mais extrêmement puissant. Avec le temps, Vim (Vi iMproved) est venu remplacer Vi et est beaucoup plus convivial. Il comprend aussi une interface graphique (optionnelle), gVim, qui a l’apparence du Notepad dans Windows, mais avec ayant quand mêmes les commandes de réputations obscures de Vi.

Les avantages de Vim par rapport à Vi sont nombreux. Pour en nommer quelques uns, Vim permet de surligner la syntaxe, plusieurs niveaux de “undo” (et “redo”) et permet d’afficher plusieurs fichiers dans le même cadre (surtout pratique pour le mode texte).

Voici quelques commandes essentielles à Vi:

:e foo.c : ouvre un fichier (ou le crée)
:w       : sauver le fichier
:w bar.c : sauver le fichier sous le nom bar.c
:q       : quitter vi (ou fermer la fenêtre active)
:q!      : quitter vi sans sauver
i        : insérer avant le curseur    (I   : insérer au début de la ligne)
a        : insérer après le curseur    (A   : insérer à la fin de la ligne)
o        : ouvrir une ligne en-dessous (O   : ouvrir une ligne au-dessus)
J        : joindre la ligne suivante après la ligne courante
u        : undo (annuler la dernière commande)
U        : undo global pour toute la ligne
Ctrl+R   : redo (annuler la dernière commande annulée)
Ctrl+G   : Affiche des informations sur le fichier et la position du curseur
ESC      : quitter le mode d'insertion

Chercher et remplacer:

:n       : Aller à la n-ième ligne. (:1 aller au début du texte)
/foo     : Recherche le mot "foo" dans le texte (?foo cherche en arrière)
:s/ab/ba : Substituer la première occurence de "ab" par "ba"
          Pour remplacer toutes les occurences sur la ligne, :s/ab/ba/g
          (où 'g' signifie 'global')
:4,10s/ab/ba/g : Remplace toutes les occurences de "ab" par "ba" sur les lignes
                de 4 à 10. (:1,$s/ab/ba/g pour tout le texte, $ = fin)
%s/ab/ba : Remplacer toutes les occurences.

Couper/Coller, supprimer:

x        : Coupe le caractère sous le curseur (10x en supprime 10)
dd       : Coupe la ligne courante (10dd en supprime 10)
D        : Coupe à partir du curseur jusqu'à la fin de la ligne courante
yy       : Copie la ligne courante
Y        : Copie à partir du curseur jusqu'à la fin de la ligne courante
p        : Colle (paste) la dernière chaine de texte coupée/copiée
:1,4y    : Copie les lignes 1 à 5 (ce genre de préfixe s'applique à toutes les commandes)

Se promener dans plusieurs fenêtres (spécifique à vim) :

:new foo : Ouvrir une nouvelle fenêtre et lire le fichier "foo"
Ctrl+w   : Changer de fenêtre. Faire deux fois pour aller à la prochaine,
          ou faire Ctrl+w+flèche_haut pour aller à la fenêtre du haut.

Les préfixes de lignes tels que “1,30” (qui signifie “de la ligne 1 à 30”) s’appliquent à la majorité des commandes qui commencent par “:”.

Sous Vim, il est aussi possible d’activer la vérification et la colorisation de la syntaxe avec “:syntax on” (pour automatiser cette commande, il suffit de l’ajouter dans le fichier “~/.vimrc” avec la commande:

$ echo "syntax on" >> ~/.vimrc

Bref, les commandes de Vi sont très excentriques, mais par la quantité de combinaisons possibles, Vi devient un outil très efficace.

4.0 Compiler

4.1 gcc

Anciennement appelé le “GNU C Compiler”, gcc a été renommé pour “GNU Compiler Collection” depuis la version 3.0 puisqu’il peut aussi compiler le C++ (g++), Objective C, Java (gcj) et Fortran (g77). GCC possède aussi des variantes qui compilent divers langages assembleur (gas), Ada95 et Pascal.

Si vous utilisez un IDE, vous n’avez pas vraiment à vous soucier de cette section, mais elle aide à mieux comprendre comment fonctionnent les outils sur lesquels s’appuie votre IDE et vous pourriez accélérer le déboguage de votre application par une meilleure compréhension générale des outils que vous utilisez.

Voici quelques exemples de compilation d’applications, du plus simple vers le plus intéressant:

$ g++ foo.cxx

Par défaut le compilateur nomme l’exécutable “a.out”, ajoutons l’options -o pour spécifier le nom du fichier à la sortie:

$ g++ foo.cxx -o toto

Si nous avons plusieurs fichiers sources pour le même exécutable:

$ g++ foo.cxx bar.cxx -o toto

L’usage de -Wall est très fortement suggéré pour éviter les erreurs de syntaxe et afficher le maximum d’avertissements:

$ g++ -Wall foo.cxx -o toto

Lorsque l’on doit déboguer avec gdb, on peut savoir exactement à quelle ligne de code le programme a planté, et quelles étaient les variables en ajoutant l’option -g:

$ g++ -Wall -g foo.cxx -o toto

Vous pouvez aussi demander à gcc d’optimiser le code machine généré, mais étant donné que ça demande plus de temps pour compiler, il est suggéré d’utiliser cette option que lorsque vous faites la commpilation finale de votre programme. Ceci se fait par l’option -O{1,2,3}:

$ g++ -Wall -O1 foo.cxx toto

Pour exécuter l’application, il suffit de faire “./toto”. Le “./” signifie que l’on veut exécuter une application qui se situe dans le répertoire courant, tout comme “../toto” aurait exécuté une application dans le répertoire parent.

Nous verrons dans la prochaine section comment automatiser la compilation d’une application.

4.2 make

Make est un outil qui permet de simplifier et accélérer la compilation d’une application. Pour ce faire, l’application cherche un fichier “Makefile” qui indique comment compiler l’application. Tout comme GCC, make est souvent simplifié par les IDE.

Voici un exemple de Makefile:

OBJS = fichier1.o fichier2.o
EXEC = toto                # nom exécutable de l'application
CC = g++                   # nom du compilateur, aurait pû être gcc, gcj, etc..
CFLAGS = -Wall -g          # voir le "man page" de gcc pour la liste complète
DEL = rm -f                # peut varier d'un système d'exploitation à l'autre

all : $(OBJS)
     $(CC) $(OBJS) -o $(EXEC)

 # les fichiers à compiler :
fichier1.o : fichier1.cxx fichier1.h
     $(CC) $(CFLAGS) -c fichier1.cxx -o fichier1.o

fichier2.o : fichier2.cxx fichier2.h
     $(CC) $(CFLAGS) -c fichier2.cxx -o fichier2.o

 # petite fonction pour faire le ménage des exécutables:
clean :
     $(DEL) $(EXEC) $(OBJS) core

Maintenant, la commande

$ make

compilera l’application, car “make” sans paramètre exécute la première section qu’il trouve, soit “all” (ceci est une convention), puis

$ make clean

supprimera les fichiers exécutables et fichiers intermédiaires (*.o).

Make est un bon outil pour les petits projets de 2 à 10 fichiers source, mais ça peut facilement devenir encombrant lorsqu’il y a des dépendances externes. Il y a de nombreux programmes pour simplifier la gestion d’un Makefile tels que la combinaison de autoconf[2] et automake[3].

5.0 Déboguer

5.1 gdb

Gdb est le “Gnu Debugger”. Il peut être particulièrement efficace pour déboguer des applications multi-thread ou des programmes extrêment complexes, mais puisqu’il faut limiter la taille de cet article, il y a principalement deux commandes à connaître pour gdb:

Si notre programme toto plante:

$ ./toto
segmentation fault

Pas très descriptif…!

$ gdb toto
GNU gdb 5.0.90-cvs (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...

(gdb) run
Program received signal SIGFPE, Arithmetic exception.
0x804883f in main (argc=1, argv=0xbffffa24) at main.cxx:27
27              int foo = 5 / 0;

Ce qui nous permet de voir qu’à la ligne 27 de main.cxx, il y a une division par zéro.

Cet exemple était peut-être un peu trop facile, prenons un exemple plus obscur qui se produit souvent en C++:

$ gdb toto
GNU gdb 5.0
[snip, information sur gdb]
This GDB was configured as "i686-pc-linux-gnu"...

(gdb) run
Program received signal SIGSEGV, Segmentation fault.
0x400f501d in free () from /lib/libc.so.6

Le programme a buggé dans une fonction qui est dans la librairie C (une librairie de très bas niveau qui est appelée par des appels intermédiaires dans une application, mais c’est probablement la fonction qui a fait cet appel qui est la source du problème. Pour voir par où le programme a passé avant de planter, utiliser la commande “bt”, soit “backtrace”, qui permet de tracer l’exécution:

(gdb) bt
 #0  0x400f501d in free () from /lib/libc.so.6
 #1  0x40048814 in __builtin_delete () from /usr/lib/libstdc++-libc6.2-2.so.3
 #2  0x8048a94 in Pile::depiler (this=0xbffff9b8, valeur=@0xbffff948) at pile.cxx:88
 #3  0x8048b01 in Pile::vider (this=0xbffff9b8) at pile.cxx:114
 #4  0x8048b4b in Pile::~Pile (this=0xbffff9b8, __in_chrg=2) at pile.cxx:32
 #5  0x8048947 in main (argc=1, argv=0xbffffa24) at main.cxx:43
 #6  0x400a1bcc in __libc_start_main () from /lib/libc.so.6

La réponse n’est peut-être pas aussi évidente que l’exemple précédent, mais au moins nous pouvons voir qu’à la ligne #1 qu’il y a eu un problème lors de la désallocation de l’objet, d’où l’erreur fréquente en C ou C++ d’accéder à un espace mémoire du système qui n’appartient pas.

Un livre complet sur gdb[4] est disponible sur le site de GNU. Il existe aussi des interfaces graphiques à gdb, telles que ‘ddd’[5] et ‘xxgdb’.

5.2 lclint

Lclint vérifie la solidité d’applications écrites en C et permet de trouver plusieurs erreurs de sémantique et autres erreurs fréquentes. Toutefois, lclint analyse que le C.

6.0 Migrer de Windows vers Linux/Unix

Cette section traite brièvement des erreurs communes lors de la migration d’un programme de Windows vers Unix.

6.1 Transfers de fichiers

Le code source d’un programme est généralement sauvegardé dans un fichier en texte pur (contrairement à Microsoft Word qui stock ses fichiers dans un format propriétaire et binaire, illisible sans le logiciel en question), toutefois, le format texte varie selon la plateforme.

Si vous transférez un fichier texte de Windows vers Linux et que vous ouvrez le fichier à l’aide de (par exemple) l’éditeur Vi, vous verrez des caractères “^M” à la fin de chaque ligne. Ceci est causé par le fait que Microsoft Windows (héritage du DOS) termine chaque ligne par les caractères “\n\r”, tandis que Unix termine chaque ligne uniquement par “\n”.

Ces caractères ne dérangent pas la majorité des compilateurs (ex: gcc n’émettera aucun avertissement), mais si vous continuez l’édition du programme sous Unix, il existe plusieurs solutions pour les enlever:

  • Transférer par FTP en mode “Ascii” (le mode par défaut est “Binaire”). Pratique pour un seul fichier, mais trop long pour un programme complet ou un programme stocké dans une archive compressée. (éviter de transférer un fichier binaire en mode Ascii)

  • Utiliser un éditeur tel que Vim qui peut travailler avec des fichiers en format Windows ou MacOS sans avoir à convertir le fichier. Vim peut aussi convertir les fichiers à l’aide de la commande:

    :set ff=unix (ff = file format; autre format: mac, dos)

  • L’utilitaire “dos2unix” est disponible sur beaucoup de systèmes Unix (avec son inverse “unix2dos”), il suffit d’exécuter la commande:

     $ dos2unix mon_fichier.c
 $ dos2unix *.c (tout les fichiers)

  • Perl: perl -p -i.old -e ’s/\r/\n/g’ [fichiers]

6.2 Votre code est-il portable?

Certains compilateurs ou interpréteurs sont parfois trop vieux. Votre code peut fonctionner sur le compilateur en question, mais causera plusieurs erreurs ailleurs, dont:

  • Erreurs de syntaxe

C’est le cas du vieillissant, mais vénéré compilateur C/C++ de Borland (3.x?) qui roule sous Microsoft DOS 6.x. Le compilateur est loin d’être compatible à la norme ANSI/ISO C++ et accepte de nombreuses erreurs de syntaxe. Par exemple, il accepte “#include <iostream.h>;” (avec un “;” à la fin de la ligne, erreur subtile et commune au près des apprentis programmeurs C/C++). Le compilateur GNU G++ donnera l’erreur suivante:

   prog.cc:1: `#include' expects "FILENAME" or <FILENAME>

Aucune référence au “;” de trop. Petite erreur qui risque de vous faire perdre beaucoup de temps!

  • conio.h [C/C++]

Certains usagers incluent ce fichier pour effacer l’écran ou inclure de la couleur dans les sorties texte. Ceci n’est pas ANSI/ISO et fonctionne que sous DOS. Pour effacer l’écran sous Unix, faites:

       #include 
       system("clear");

Cette commande exécutera la commande shell “clear”.

  • Errers de sémantique et comportements indéfinis:

Plusieurs langages (Lisp, C, C++ surtout) ont des opérations qui n’ont pas de comportement défini ou ont un comportement aproximatif. Le simple fait de changer de compilateur/interpréteur, de système d’exploitation (Win -> Unix -> Linux -> Mac) ou d’architecture (Intel -> Sparc -> PowerPC) peut fausser les résultats d’une application.

À ma connaissance, aucun compilateur détecte ce genre d’erreurs causée par la perte de précision dans les nombres réels causé par la conversion d’un mombre décimal vers le binaire. Voici un exemple (très vulgarisé) de code à éviter:

float a = 2;
float b = 1;

a /= 3;
b /= 3;

if(a/3 == b/3 * 2)
  arreter_reacteur_nucleaire();

Même si la syntaxe est correcte, la condition ne sera jamais atteinte. Soyez sûr de bien connaître le langage et l’architecture avec lesquels vous programmez et ne vous contentez pas du simple fait que le programme compile.

  • Librairies, APIs et extentions spécifiques à une plateforme:

Si vous avez une application avec des “DLL”, ces derniers devront être convertis (shared libraries). Si vous n’avez pas leur code source ou s’ils sont étroitement reliés au système d’exploitation, vous devrez trouver des alternatives. Desfois il est possible de porter une application à l’aide de l’API “Wine” (Wine Is Not an Emulator) qui est une implémentation Libre de l’API win32 et (partiellement?) DirectX/Direct3D. Toutefois, ceci déborde le contexte de ce document. Voir la section 8 (Références) pour des liens.

7.0 Conclusion

N’oubliez pas que chaque application possède une courbe d’apprentissage. Il y a généralement deux catégories: soit l’apprentissage est difficile au début, mais l’application est très flexible et efficace (courbe de la fonction exponentielle), tandis que d’autres sont très faciles dès le début, mais les fonctionalités plus avancées sont soit inexistantes ou inutilement complexes (courbe de la fonction racine carrée).

Sous Linux (et Unix en général) vous avez le choix entre une multitude d’applications, il suffit de faire une bonne combinaison de logiciels pour ainsi combiner les deux courbes à votre avantage.

8.0 Références

8.1 Général

Linux : http://www.linux.org/, http://www.linux.com/ FreeBSD : http://www.freebsd.org/ OpenBSD : http://www.openbsd.org/ NetBSD : http://www.netbsd.org/

Gnome : http://www.gnome.org/ KDE : http://www.kde.org/

8.2 Éditeurs

Code Crusader : http://www.newplanetsoftware.com/ KDevelop : http://www.kdevelop.org/ jEdit : http://jedit.sourceforge.net/ NEdit : http://nedit.org/ Emacs : http://www.gnu.org/software/emacs/emacs.html XEmacs : http://www.xemacs.org/ Vim/gVim : http://www.vim.org/

8.3 Autres

GCC : http://www.gnu.org/software/gcc/gcc.html GJC : http://sources.redhat.com/java/ lclint : http://lclint.cs.virginia.edu/ Wine : http://www.winehq.com/

8.4 Sites mentionnés dans ce texte

1 - The Art of Unix Programming: http://www.tuxedo.org/~esr/writing/taoup/ 2 - GNU : http://www.gnu.org/ Philosophie: http://www.gnu.org/philosophy/free-sw.fr.html 3 - OpenSource : http://www.opensource.org/ 4 - Debugging with GDB: http://www.gnu.org/manual/gdb-4.17/html_mono/gdb.html 5 - Manuel de DDD: http://www.gnu.org/manual/ddd/index.html

8.5 Sites complémentaires