FAQ C++Consultez toutes les FAQ

La fonction standard std::system() définie dans <cstdlib> permet d'exécuter la commande qui lui est fournie en paramètre au moyen de l'interpréteur de commande du système d'exploitation.
Son comportement est donc spécifique à chaque OS.

1
2
3
4
5
6
7
8
9
10
#include <cstdlib>  
  
int main()  
{  
    // exécute la commande système "dir"  
    // le texte affiché dépend de l'OS  
    std::system( "dir" );  
    // exécute le programme "toto.exe"  
    std::system( "toto.exe" );  
}

_exec

_spawn

Cette question se destine tout d'abord aux responsables non techniques et au personnel des ressources humaines qui essaient de faire un travail de bonne qualité quand ils interviewent des candidats développeurs C++. Si vous êtes un programmeur C++ sur le point d'être interviewé, et que vous consultez cette FAQ en espérant savoir à l'avance quelles questions vont vous être posées de façon à ne pas devoir apprendre réellement le C++, honte à vous. Prenez le temps de devenir un développeur compétent et vous n'aurez pas besoin d'essayer de tricher.

Pour revenir aux non techniciens et au personnel des ressources humaines : il est évident que vous êtes parfaitement qualifiés pour juger si un candidat a un profil correspondant à la culture de votre entreprise. Cependant, il y a assez de charlatans, de menteurs et de frimeurs pour que vous ayez besoin de faire équipe avec quelqu'un qui est techniquement compétent pour s'assurer que le candidat ait le niveau technique adéquat. Assez de sociétés ont souffert d'avoir engagé des gens sympathiques mais incompétents, des gens globalement incompétents malgré le fait qu'ils connaissent les réponses à quelques questions très pointues. La seule façon de démasquer les menteurs et les frimeurs est d'avoir à vos cotés une personne capable de poser des questions techniques pointues. Il n'y a aucun espoir que vous y arriviez par vous-même. Même si je vous donnais une série de questions pièges, elles ne vous permettraient pas de démasquer ces personnes.

Votre partenaire technique n'a pas besoin d'être qualifié (et bien souvent, il ne l'est pas) pour juger la personnalité du candidat, donc, par pitié, n'oubliez pas que vous êtes le seul juge au final. Mais ne pensez pas que vous pouvez poser une demi-douzaine de questions sur le C++ et avoir la moindre chance de savoir si le candidat sait de quoi il parle, du moins d'un point de vue technique.

Par contre, si vous avez un niveau technique suffisant pour lire cette FAQ, vous pouvez y piocher quantité de bonnes questions pour une interview. La FAQ contient bon nombre de choses permettant de séparer le bon grain de l'ivraie. La FAQ se concentre sur ce que les programmeurs doivent faire, plutôt que d'essayer de voir ce que le compilateur leur laisse faire. Il y a des choses en C++ qu'il est possible de faire mais qu'il vaut mieux éviter. La FAQ sert à faire le tri là-dedans.

Voici quelques astuces pour réduire les temps de compilation, qui peuvent parfois se compter en minutes voire en heures sur des projets de taille conséquente.

1. Utiliser les déclarations anticipées
   Si dans un en-tête vous ne déclarez qu'un pointeur ou une référence sur une classe, alors vous n'avez pas besoin d'inclure son en-tête : une déclaration anticipée suffit.
   
   MaClasse.h
   
   

   Code c++ :

   Sélectionner tout

   1
   2
   3
   4
   5
   6
   7
   8
   9
   class Classe1; // pas d'inclusion de "Classe1.h" 
   class Classe2; // pas d'inclusion de "Classe2.h" 
     
   class MaClasse 
   { 
       void Something(const Classe1& c); 
     
       Classe2* c2; 
   };

   MaClasse.cpp
   
   

   Code c++ :

   Sélectionner tout

   1
   2
   3
   4
   5
   6
   7
   8
   #include "Classe1.h" 
   #include "Classe2.h" 
     
   void MaClasse::Something(const Classe1& c) 
   { 
       // Ici on peut accéder aux membres de Classe1 et Classe2, 
       // on a inclus leurs en-têtes 
   }

   Ainsi lorsque Classe1 ou Classe2 sera modifiée, seul MaClasse.cpp sera recompilé. Sans cette astuce, vous auriez dû recompiler (inutilement) tous les fichiers incluant MaClasse.h. L'élimination des dépendances inutiles est essentielle pour améliorer les temps de compilation.
2. Utiliser l'idiome enveloppe-lettre, appelé aussi Pimpl (Private Implementation)
   Le principe de cet idiome est de séparer l'interface publique d'une classe de son implémentation.
   
   MaClasse.h (interface)
   
   

   Code c++ :

   Sélectionner tout

   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   class MaClasseImpl; 
     
   class MaClasse 
   { 
   public : 
     
       void Set(int); 
       int Get() const; 
     
   private : 
     
       MaClasseImpl* pImpl; 
   };

   MaClasse.cpp
   
   

   Code c++ :

   Sélectionner tout

   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   #include "MaClasseImpl.h" 
     
   void MaClasse::Set(int x) 
   { 
       pImpl->Set(x); 
   } 
     
   int MaClasse::Get() const 
   { 
       return pImpl->Get(); 
   }

   MaClasseImpl.h (implémentation)
   
   

   Code c++ :

   Sélectionner tout

   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   class MaClasseImpl 
   { 
   public : 
     
       void Set(int); 
       int Get() const; 
     
   private : 
     
       int val; 
   };

   MaClasseImpl.cpp
   
   

   Code c++ :

   Sélectionner tout

   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   #include "MaClasseImpl.h" 
     
   void MaClasseImpl::Set(int x) 
   { 
       val = x; 
   } 
     
   int MaClasseImpl::Get() const 
   { 
       return val; 
   }

   Ainsi, seule une modification de l'interface de MaClasse entraînera une recompilation des fichiers qui en dépendent. Un changement dans son implémentation n'entraînera la recompilation que de deux fichiers au maximum : MaClasse.cpp et MaClasseImpl.cpp.
   Comme vous le voyez dans cet exemple, MaClasse est ici limitée à son interface publique, toutes ses données privées et protégées sont cachées dans MaClasseImpl. C'est un autre avantage de ce procédé : en plus de réduire les dépendances et d'accélérer la compilation, l'idiome pimpl permet de ne rendre visible pour les clients d'une classe que son interface publique.
   
   Pour plus de détails sur l'idiome pimpl, nous vous invitons à consulter ces liens tirés de GOTW :
   
   • http://www.gotw.ca/gotw/024.htm
   • http://www.gotw.ca/gotw/028.htm
     
3. Utiliser les en-têtes précompilés
   En plus des techniques citées ci-dessus, certains environnements de développement comme VC++ et BCB proposent d'utiliser un en-tête précompilé. Pour en tirer partie il faut :
   
   • Activer son utilisation dans les options du projet.
   • Inclure dans l'en-tête précompilé (par défaut, stdafx.h sous VC++) tous les en-têtes que vous ne modifierez pas ou peu souvent (en-têtes standards, de bibliothèques externes…).
   • Inclure l'en-tête précompilé dans toutes les unités de traduction (les .cpp) du projet.
     
   
   

   	Si vous y incluez un en-tête subissant des modifications fréquentes cela aura l'effet inverse : à chaque modification de celui-ci vous aurez droit à une recompilation complète.

   
   

C'est tout à fait normal. Cela est dû au codage interne des flottants en mémoire (selon la norme IEEE 754). Ces imprécisions deviennent d'autant plus gênantes qu'elles s'accumulent en même temps que les opérations que vous effectuez sur vos nombres ; ainsi il est tout à fait possible d'obtenir des nombres très éloignés des résultats théoriques.

Il n'existe pas de solution miracle, cependant vous pouvez tout de même trouver un compromis selon vos besoins :

-> Vous avez besoin d'une précision exacte (gestion de comptes ou autres applications monétaires) : utilisez plutôt ce que l'on appelle les nombres en virgule fixe, qui, généralement codés sous forme d'entiers, ne souffrent pas de ces imprécisions. Le C++ ne dispose pas en standard de types en virgule fixe, mais vous pourrez facilement trouver des classes ou des bibliothèques toutes faites, voire construire la vôtre.

-> Vous voulez tenir compte des imprécisions dans vos calculs : utilisez un epsilon (nombre très petit) lors de vos tests de comparaison. Typiquement, l'espilon choisi dépend de votre application et des grandeurs manipulées. Un point de départ est l'espilon défini dans la bibliothèque standard (std::numeric_limits<float>::epsilon() pour les float par exemple), qui définit le plus petit flottant tel que 1 + espilon > 1. Ainsi vos comparaisons deviennent :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <cmath> // pour std::abs 
#include <limits> // pour std::numeric_limits 
  
using namespace std; 
  
float f1 = 0.1f; 
float f2 = 1.1f; 
float f3 = f2 - f1; 
  
// Version incorrecte ne tenant pas compte des imprécisions 
if (f3 == 1.0f) 
{ 
    // Pratiquement jamais vrai ! 
} 
  
// Version correcte tenant compte des imprécisions 
// err est une variable choisie en fonction de l'erreur autorisée 
if (abs(f3 - 1.0f) <= err * max(abs(f3), abs(1.0f)) * numeric_limits<float>::epsilon()) 
{ 
    // Ok 
}

Lorsque l'on veut écrire du code portable, il est parfois nécessaire d'utiliser la compilation conditionnelle, c'est-à-dire compiler tel ou tel code selon la plateforme sur laquelle on se trouve.

Par exemple, voici un code qui sera capable de compiler correctement à la fois sous Windows et sous Unix :

1
2
3
4
5
6
7
8
#if defined (linux) 
    // Code spécifique à Linux 
#elif defined (_WIN32) 
    // Code spécifique à Windows 
#else 
    // Plateforme non gérée, on peut par exemple placer une erreur de compilation 
    #error Plateforme non gérée 
#endif

• Standard.
• Compilateurs.
• Systèmes d'exploitation.
• Bibliothèques.
• Architectures.
  

Une lvalue est, à l'origine, une expression qui peut se trouver du côté gauche lors d'une affectation, c'est-à-dire une expression à laquelle on peut affecter quelque chose. Désormais, une lvalue désigne toute expression qui fait référence à un objet, c'est-à-dire toute expression qui fait référence à une région contigüe de mémoire. Cela peut donc être par exemple un objet constant, ce qui ne rentre pas forcément dans la définition utilisant l'affectation.

Par conséquent, les identifiants (de variables) sont des lvalues. Il en va de même pour les références.

Voici un code qui va peut-être aider à la compréhension :

1
2
3
4
5
6
int n = 5; // n est une lvalue 
Client& getClient() { /* ... */ } 
getClient() = UnAutreClient; // getClient() désigne ici une lvalue car la référence renvoyée correspond à la définition d'une lvalue 
  
std::string s = "C++"; // s est une lvalue 
// ...

Les variables volatiles sont des variables qui peuvent être modifiées par un processus hors de contrôle du compilateur. On doit accéder à une copie de la variable si elle a pu être modifiée.
Seules des fonctions membres volatiles peuvent être appelées pour des objets volatils, et des fonctions membres volatiles ne peuvent appeler que des autres fonctions membres volatiles. La viralité peut être détournée.
Le compilateur s'assure qu'aucune fonction membre n'ait d'optimisation quant aux références mémoire. En l'absence du mot-clef volatile, il peut optimiser le code de la fonction membre.
Cependant, la présence de ce mot-clef n'empêchera pas le processeur d'optimiser pour la cohérence des caches.
Utilisez ce mot-clef pour des variables que vous ne voulez pas voir optimisées par le compilateur.
Il est faux de penser que ce mot-clef apporte la moindre sécurité face au mutlithread. Il faut pour cela attendre le mot-clef atomic du C++0x.
Voici un petit exemple d'utilisation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class Gadget 
{ 
public: 
    void attendre() 
    { 
        while (! _drapeau) 
        { 
            dormir(1000); // attend 1000 ms 
        } 
    } 
    void seLever() 
    { 
        _drapeau = true; 
    } 
    // ... 
private: 
    volatile bool _drapeau; 
};

On parle d'immuabilité (ou non-mutabilité) d'un élément (au sens large) lorsque celui-ci ne change pas, tout au long de sa durée de vie. En C++, il faut distinguer plusieurs cas d'immuabilité :

• immuabilité de membres ;
• immuabilité des paramètres ;
• fonctions membres ne modifiant pas l'objet ;
• types immuables.
  

1
2
3
4
class C { 
    int const TAILLE_MAX; 
    // [...] 
};

1
2
3
4
int longueur(std::string const & chaine) 
{ 
    // [...] 
}

1
2
3
4
5
class chaine { 
public: 
    int longueur() const; 
    // [...] 
};

• Dans une fonction membre const, les membres pointeurs sont de type X* const, et non X const * const. Ceci fait qu'il est tout à fait légal d'écrire le code suivant :
  
  

  Code c++ :

  Sélectionner tout

  1
  2
  3
  4
  5
  class A { 
      int * m_val; 
  public: 
      int IncrementByOne() const { return  ++(*m_val); } 
  };

  Pour justifier ce comportement, prenez l'exemple d'un smart_pointer. Il est logique qu'un smart_ptr<int> const se comporte de la même manière qu'un int * const, tandis qu'un smart_ptr<const int> se comportera comme un int const *.
• Les membres déclarés avec le mot clé mutable ignorent les règles d'immuabilité imposées par const. Ceci permet des implémentations par compteur de références sur des objets const, par exemple.
• Il est possible à tout moment, au moyen de const_cast, de forcer la mutabilité d'une variable immuable.
  

Il arrive que l'on veuille charger une bibliothèque dynamique (.dll, .so) explicitement depuis le code C++, que ce soit pour implémenter un système de plugins ou tout simplement car on ne dispose pas des fichiers de lien statique (.lib, .a). Cette manipulation est spécifique à chaque système, mais on peut cependant remarquer que les principes et les fonctions mis en jeu sont pratiquement équivalents, au nom près.
En l'occurrence, cela se fait en trois étapes :

• Charger la bibliothèque dynamique
• Récupérer les fonctions qu'elle exporte
• Décharger la bibliothèque dynamique
  

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
// Version pour Windows 
#if defined(_WIN32) || defined(__WIN32__) 
  #include <windows.h> 
  #define DYNLIB_HANDLE         HMODULE 
  #define DYNLIB_LOAD( a )      LoadLibrary( a ) 
  #define DYNLIB_GETSYM( a, b ) GetProcAddress( a, b ) 
  #define DYNLIB_UNLOAD( a )    !FreeLibrary( a ) 
  #define DYNLIB_ERROR( )       "Unknown Error" 
  
// Version pour Linux 
#elif defined(linux) || defined(__linux) 
  #include <dlfcn.h> 
  #define DYNLIB_HANDLE         void* 
  #define DYNLIB_LOAD( a )      dlopen( a, RTLD_LAZY ) 
  #define DYNLIB_GETSYM( a, b ) dlsym( a, b ) 
  #define DYNLIB_UNLOAD( a )    dlclose( a ) 
  #define DYNLIB_ERROR( )       dlerror( ) 
#endif 
  
#include <iostream> 
  
int main() 
{ 
    // Chargement de la bibliothèque 
    DYNLIB_HANDLE Lib = DYNLIB_LOAD("library"); 
    if (!Lib) 
    { 
        std::cerr << DYNLIB_ERROR() << std::endl; 
        return EXIT_FAILURE; 
    } 
  
    // Importation de la fonction qui nous intéresse 
    typedef int (*FuncType)(float); 
    FuncType Func = static_cast<FuncType>(DYNLIB_GETSYM(Lib, "Function")); 
    if (!Func) 
    { 
        std::cerr << DYNLIB_ERROR() << std::endl; 
        return EXIT_FAILURE; 
    } 
  
    // Appel de la fonction importée 
    int x = Func(5.f); 
  
    // Déchargement de la bibliothèque 
    if (DYNLIB_UNLOAD(Lib)) 
    { 
        std::cerr << DYNLIB_ERROR() << std::endl; 
        return EXIT_FAILURE; 
    } 
  
    return EXIT_SUCCESS; 
}