| ||
auteur : Aurélien Regat-Barrel | ||
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.
L'appel à cette fonction ne rend pas la main tant que la commande n'a pas terminé son exécution.
Si vous souhaitez un comportement différent (que la fonction rende la main immédiatement, qu'une console ne soit pas crée, rediriger les flux standard, ...), il faut vous tourner vers une solution spécifique à votre système d'exploitation. Voir les fonctions CreateProcess / ShellExecute[Ex] sous Windows, et les fonctions de type exec*() et spawn() définies dans les headers <unistd.h> / <process.h> pour les systèmes UNIX/POSIX (Notez qu'elles sont aussi disponibles avec un underscore préfixé à leur nom sous Visual C++) |
| ||
auteurs : Aurélien Regat-Barrel, Laurent Gomila | ||
C++0x est le nom de code de la prochaine version de l'actuel standard ISO C++ 98,
qui porte le nom de C++98.
Cette future norme devrait être ratifiée d'ici 2009, et le 'x' dans son nom de code
sera alors remplacé par l'année en cours (par exemple, C++09 si cela a lieu en 2009).
Faire évoluer un langage tel que le C++ est une tâche complexe qui nécessite du temps.
Conscient que C++0x ne serait pas ratifié avant la fin de la décénie,
le commité de normalisation ISO a entrepris et achevé en 2005 la rédaction d'un document intermédiaire
limité au développement d'extensions à la bibliothèque standard du C++.
Vous pouvez lire à ce sujet Qu'est-ce que le Library Technical Report (tr1 / tr2) ?.
Voici quelques liens vers des documents sur le sujet:
On peut également trouver des brouillons du prochain standard à cette adresse :
C++ Standards Committee Papers.
|
| ||
auteur : Aurélien Regat-Barrel | ||
Le Technical Report on C++ Library Extensions
est le premier Technical Report (TR1)
consacré à la bibliothèque standard du C++.
Il a été réalisé en 2005, et constitue une sorte de brouillon officiel
décrivant un ensemble d'extensions à la bibliothèque standard actuelle suceptibles d'être adoptées dans
C++0x.
Un deuxième document du même type est actuellement à l'étude (TR2).
Un Technical Report n'est pas normatif, c'est à dire qu'il ne fait pas officiellement partie de la norme,
et ne garantit pas que ce sera le cas dans le futur.
Les distributeurs de compilateurs ne sont pas obligés non plus de développer et fournir ces extensions.
Un autre élément important est que les extensions proposées s'appuient sur les capacités actuelles du langage C++,
et non sur les futures possibilités de C++0x.
Cependant, un TR (Technical Report) préfigure fortement ce que sera la prochaine norme C++, et l'objectif d'un tel document est double:
Au niveau pratique, toutes les nouveautés introduites par le TR1 le sont au sein
d'un nouveau namespace tr1 membre du namespace standard std.
De nombreux éléments sont directement issus de la bibliothèque boost.
On retrouve par exemple les fameux shared_ptr (voir Comment utiliser les pointeurs intelligents de Boost ?),
qui ont été intégrés aux côtés de std::auto_ptr dans le fichier d'en-tête <memory> (voir Pourquoi faut-il se méfier de std::auto_ptr ?):
Les principales extensions issues de boost et incluses dans le TR1 sont:
Pour plus de détails, vous pouvez aussi lire
Library Technical Report.
Mais le TR1 ne se résume pas à la récupération de bibliothèques de Boost.
Il y a aussi de nombreuses nouveautés issues du C99 et un enrichissement important
des fonctions mathématiques.
Plusieurs compilateurs et développeurs de bibliothèque standard se sont lancés dans leur propre implémentation du TR1.
C'est le cas de GCC et de CodeWarrior par exemple,
ainsi que de Dinkumware qui est le premier a l'avoir implémenté à 100%
(Dinkumware est aussi le fournisseur de la STL de VC++, ce qui laisse penser que ce dernier supportera lui aussi le TR1).
Les développeurs de Boost se sont bien sûr eux aussi atelés à la tâche, et
Boost.TR1
est actuellement en cours de développement.
|
| ||
auteur : Marshall Cline | ||
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.
|
| ||||||
auteur : Laurent Gomila | ||||||
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
MaClasse.cpp
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)
MaClasse.cpp
MaClasseImpl.h (implémentation)
MaClasseImpl.cpp
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 :
Attention, 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.
|
| ||
auteurs : Laurent Gomila, Jean-Marc.Bourguet | ||
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 :
|
| ||
auteur : Laurent Gomila | ||
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 :
Cependant, connaître toutes les macros prédéfinies pour chaque OS, compilateur, ... est très difficile.
La solution la plus rapide est d'aller visiter le site Pre-defined C/C++
Compiler Macros, qui maintient une liste à jour des macros prédéfinies pour les choses suivantes :
Une bonne habitude est également d'aller regarder les en-têtes de bibliothèques portables
(par exemple boost). Ceux-ci sont truffés de conditions sur les plateformes, et vous donneront
de bonnes informations.
|
| ||
auteurs : Laurent Gomila, JolyLoic, Mat007 | ||
En plus de ses mots-clé, le C++ réserve certains identificateurs, notamment pour l'implémentation de la bibliothèque standard ou pour les ajouts
propriétaires que l'on peut trouver sur la plupart des compilateurs. Cela assure qu'il n'y aura aucun conflit entre votre code et celui livré par le compilateur,
qui ne sera pas forcément documenté.
En outre, la norme réserve (et donc interdit) les identificateurs suivant :
Une version simplifiée de cette règle est donc de ne pas commencer ses noms par un _ du tout, ni d'utiliser __.
|
| ||
auteur : r0d | ||
Un type POD (de l'anglais Plain Old Data) est un type C++ qui a un équivalent en C, et qui utilise les mêmes règles que le C
pour l'initialisation, la copie et l'adressage.
La définition précise d'un type POD est récursive et un peu absconse. Voici une définition légèrement simplifiée:
les données membres non statiques d'un type POD doivent être publiques et peuvent être de ce type:
Notez que les références ne sont pas permises pour un type POD. De plus, un type POD ne peut pas avoir ni constructeur, ni fonction
virtuelle, ni de classe de base (pas d'héritage), ni de surcharge d'opérateur d'assignation.
Dans certaines situations, le C++ permet uniquement l'utilisation de POD. Par exemple, une union ne peut pas contenir une
classe qui a des fonctions viruelles ou des ctors non triviaux. Les PODs peuvent également être utilisés pour interfacer du
code C++ avec du code C.
|
Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2008 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.