L'avantage du C++ c'est avant tout le RAII.
Pouvoir redéfinir les sémantiques de copie, d'affection, de construction et de destruction de nouveaux types qu'on définit permet de ne pas avoir à faire de gestion manuelle des ressources (comme la mémoire) en garantissant que tout est libéré même face à des erreurs qui surviennent durant l'exécution (exceptions).
À lui seul, cet idiome empêche 90% des défauts de C d'apparaître (gestion de mémoire manuelle, fuites mémoires, dangling pointers...).
Le deuxième avantage, c'est la programmation générique. On peut programmer des composants réutilisables sans avoir à utiliser du typage ou du dispatch dynamique.
Les langages de la famille ML se vantent de leur polymorphisme paramétrique et de leurs modules, mais les fonctionnalités pour la programmation générique de C++ (les templates) permettent bien plus de choses, et sont plus faciles à comprendre pour un programmeur proche du système (mais peut-être pas pour un fan de lambda-calcul).
Celle-ci peut toutefois parfois être compliquée si on veut réaliser certaines choses car nécessitant d'exploiter un peu de méta-programmation pour vérifier certaines propriétés sur les types. De bons outils, comme ceux de boost, peuvent toutefois fortement aider.
La programmation générique sera grandement simplifiée par l'introduction en C++0x des concepts. Ceux-ci permettent de vérifier simplement certaines propriétés sur des types, d'une façon similaire à l'héritage, mais de manière non-intrusive (sans que le type soit explicitement défini comme sous-typant un certain autre type -- le sous-typage est implicite).
Certains aspects de la programmation générique resteront toujours complexes et pour les gurus, comme la réalisation d'un DSEL, même si boost.proto aide beaucoup.
L'héritage permet d'avoir du polymorphisme dynamique à la Java, ce qui est souvent synonyme de programmer plus ou moins à la Java, avec des pointeurs dans tous les sens, de la sémantique d'entité et de la gestion de mémoire "globale" (refcounting ou GC).
Bien évidemment, programmer avec l'héritage, une sémantique de valeur et une gestion de mémoire "non globale" peut se faire, mais en pratique ce n'est pas fait.
Les gens adeptes de cette approche, quand ils codent proprement, utilisent alors plutôt shared_ptr.
La mode actuelle vers laquelle se dirige le C++ moderne est cependant de ne pas utiliser l'héritage, mais de préférer le sous-typage implicite non-intrusif, comme les concepts donc, et avec des objets valeurs (qui restent implémentés par des fonctions virtuelles et des templates sous le capôt) .
Un exemple populaire étant function<R (T1... TN)>, qui permet de contenir un objet de n'importe quel type à partir du moment où on peut l'appeler avec la signature choisie. D'autres exemples plus génériques sont boost.any et choses similaires.
Le futur étant quelque chose dans le genre de adobe::poly -- qui a eu quelques publications scientifiques ces derniers temps [1] --, qui permet vraiment d'avoir de la programmation générique comme avec les templates avec du polymorphisme dynamique au lieu du polymorphisme statique qui les caractérise.
L'héritage multiple etc. est vraiment très peu utilisé. Principalement par la programmation par contrats ou par les frameworks fortement orientés objet (comme le sont bien souvent les GUI toolkits).
Donc réellement, les aspects intéressants du C++ sont le RAII et les templates.
Dire que ce sont des fonctionnalités complexes uniquement pour utilisateurs avancés me semble donc une aberration.
Si ces aspects ne sont pas bien connus par la personne, ou pas utilisés, je pense donc que celle-ci passe vraiment à côté de ce qu'est C++.
Le K&R (dans sa dernière version) est un livre d'exercices pour apprendre le C89.
Ce n'est nullement la norme. La grammaire n'est qu'une toute petite partie de la définition d'un langage, le plus important c'est la sémantique.
Elle ne fait que la moitié de la taille du standard C++0x, mais comme je l'ai dit, si tu compares certains passages tu constateras que là où le standard C est flou et pas clair le standard C++ est explicite.
De plus, bon, il parait évident que C++0x est un peu plus compliqué que C99, car ayant plus de fonctionnalités, donc c'est plus long à définir.
Ce qui est bizarre c'est que tout le monde crache sur C++ et qu'en même temps tout le monde complimente Qt.
Au contraire, les adeptes du C++ moderne adorent C++ et n'aiment pas trop Qt.
En effet, Qt n'est pas écrit en C++ mais en C++/MOC, afin d'y rajouter des fonctionnalités qui se font très bien de manière native, de manière plus élégante et surtout de manière type-safe.
De plus, Qt a ses propres conteneurs etc. et donc dédouble une partie importante de choses mieux réalisées par d'autres bibliothèques, en partie la bibliothèque standard.
Et pour finir, utilisation intensive de pointeurs etc., contraire aux idiomes standards de la programmation en C++.
Certaines choses sont exprimées à la fois dans le standard C et dans le standard C++.
Et bien C est bien plus court, mais est totalement incompréhensible...
Le fait que le standard C++ soit plus long lui permet d'être clair et précis.
Le frontend propriétaire EDG (utilisé notamment par le compilateur Comeau) supporte à 100% le standard C++98 et les corrections de 2003.
Pour ce qui est du non-respect des standard, c'est à cause de cela que la plupart des codes ne compilent plus.
Le fait que ça marche à cause d'un comportement erroné ou non documenté du compilateur ne devrait pas être exploité.
Parser du C++ n'est pas trivial. En particulier, la syntaxe n'est pas LALR et l'analyse sémantique doit se faire en même temps.
Je doute qu'un tel outil en soit capable, étant donné que même le fameux Doxygen n'a qu'un parser C++ approximatif.
L'ASLR n'a aucun intérêt à part diminuer les performances.
Ça ne fait que rendre certains bugs plus difficilement exploitables, bugs qui ne devraient pas exister si le programmeur savait utiliser des idiomes sûrs de programmation.
La présentation d'Alan Cox sur le SMP, hautement intéressante, n'a reçu que très peu de questions, et aucune question intéressante.
Il a du insister à plusieurs reprises pour avoir des questions, et a même demandé que lui pose des questions sur n'importe quel sujet et pas nécessairement sur sa présentation.
Alors que, vu le sujet, il y avait de très intéressantes questions à poser, surtout qu'il s'agit d'un développeur assez important du noyau linux.
Ça me fait un peu mal au coeur de voir que le public soit aussi mauvais. Je me demande même ce que les intervenants internationaux doivent penser de la France quand ils voient des interactions pareilles...
Admettons. Mais quand je programme en multi-thread, le problème de l'utilisation de nptl ou le "truc" windows est mineur par rapport à déterminer ce qui doit être locké (protégé), les fifo, rechercher les conditions de deadlock, utiliser un semaphore ou seulement un lock, quand mettre un signal, etc... Surtout si on veut profité à plein d'un système multi-cpu. Mettre un gros lock qui sérialise tout est une solution de facilité.
Et ça TBB ne t'aide pas. C'est à toi de faire tourner ton cerveau.
Chacun sait que les verrous sont une mauvaise façon de gérer la concurrence.
Utilise plutôt du message passing.
http://llvm.org/nightlytest/
Choisis une machine, clique sur "view details", puis sur "full test results", puis regarde la colonne GCC/LLC.
Une valeur supérieure à 1 signfie que LLVM est plus rapide.
De plus, moi qui aime bien regarder l'assembleur généré par mes programmes, je remarque qu'avec LLVM il y a une bien meilleure propagation des constantes et un meilleur inlining.
Ça inline même les fonctions virtuelles... chose dont GCC est incapable.
La dépêche dit que les performances de LLVM sont proches de GCC, laissant suggérer que LLVM est quelque peu plus lent.
C'est faux : le code compilé par LLVM est bien plus rapide qu'avec GCC, simplement parce que LLVM fait des optimisatons plus poussées, en particulier à l'édition de liens.
Le format intermédiaire de LLVM, de type SSA, a justement été choisi car il permettait la mise en place des tous derniers algorithmes d'optimisations issus de la recherche.
LLVM a, comme il a été dit dans un autre message, été choisi par le projet Mesa, qui va en faire des backends pour les cartes graphiques modernes. Ce qui signifie qu'à terme on pourra exécuter, en plus de GLSL, du C ou même du Python, le tout optimisé, sur son GPU.
Les techniques usuelles pour gérer la concurrence, à base de verrous etc., ne sont pas génériques et applicables de manière sûre dans tous les cas.
C'est pour cela qu'on a élaboré des modèles sûrs, avec des abstraction de haut niveau, pour la programmation concurrentielle : le message passing surtout, mais aussi un peu les transactions.
On le voit bien avec l'avènement des langages orientés concurrence comme Erlang, Concurrent Haskell, (ou même JOCaml ou C-omega pour les fans du Join-calcul, création française), ou avec des bibliothèques comme CCR (Coordination and
Concurrency Runtime -- truc .NET) ou Intel Threading Building Blocks.
OpenMP n'est pas là pour faire du passage de message, ni pour faire dans la transaction mémoire.
En effet, il est là pour introduire des algorithmes exploitant le parallélisme d'une manière peu élégante.
Les pragmas OpenMP ne sont PAS des macros.
Ce sont des pragmas, qui sont des sortes de macros.
Donc ce sont plus ou moins des macros. Ce que je voulais dire de toutes façons, c'est que cela ne s'intégrait pas au langage.
Le standard ne décrit aucun des algorithmes que tu cites
"for" est un algorithme.
Pourquoi en faire quelque chose de dynamique uniquement, quand on est potentiellement capable de détecter à la compilation certaines propriétés importantes pour le parallélisme ?
Je serais fort intéressé de voir un cas où un "for" parallélisé avec OpenMP peut être plus rapide qu'avec une solution sous forme de bibliothèque.
Du point de vue du programmeur d'applications scientifiques, l'utilisation d'OpenMP simplifie grandement la programmation d'applications ayant des sections parallèles : sans avoir à mettre en oeuvre toute la mécanique nécessaire à la parallélisation façon MPI, un programmeur qui sait qu'une portion de son code est parallèle pourra facilement découper celui-ci, en rajoutant un bête #pragma omp parallel
{
____#pragma omp for
____for (i = 0; i < N; i++) {
________/* code parallèle ici */
____}
}
En quoi est-ce plus simple que parallel_for(blocked_range<int>(0, N), /* code parallèle ici sous forme de fonction */);
deuxième forme qui s'intègre bien mieux dans le langage, bien plus générique par ses aspects fonctionnel et d'intervalle (qui peut fonctionner avec tout type d'itérateur), et qui ressemble fortement à std::for_each ?
(Cet algorithme est disponible tel quel dans Intel Threading Building Blocks)
Il n'y a que deux façons de traiter d'une manière propre la concurrence : le message passing ou la software transactional memory.
Les deux sont génériques et peuvent s'appliquer à tous types d'architecture parallèle. Erlang implémente le premier modèle, Haskell le second.
OpenMP n'apporte aucune de ces deux solutions.
La seule chose relativement utile, ce sont ses algorithmes pré-écrits qui exploitent le parallélisme. Algorithmes qui seraient bien mieux sous forme de bibliothèque comme par exemple ceux de la bibliothèque standard de C++, plutôt que sous forme de macros horribles intégrées au langage.
# Mauvais type MIME
Posté par loufoque . En réponse à la dépêche Le groupe sensibilisation de l'April publie une nouvelle version de l'Expolibre. Évalué à 2.
Du coup, ils s'affichent dans un navigateur comme du texte, et nous comme des documents SVG.
[^] # Re: gcc lave plus blanc ?
Posté par loufoque . En réponse à la dépêche Sortie de GCC 4.3. Évalué à -5.
Donc, d'après ton raisonnement, si j'écris du Python, j'écris en fait du C ?
Quant a ton document, il ne donne aucun réel argument.
À noter que le système d'introspection et de propriété n'amène rien du tout, si ce n'est un système particulièrement inélégant de typage dynamique.
[^] # C++ : RAII et programmation générique
Posté par loufoque . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 8.
Pouvoir redéfinir les sémantiques de copie, d'affection, de construction et de destruction de nouveaux types qu'on définit permet de ne pas avoir à faire de gestion manuelle des ressources (comme la mémoire) en garantissant que tout est libéré même face à des erreurs qui surviennent durant l'exécution (exceptions).
À lui seul, cet idiome empêche 90% des défauts de C d'apparaître (gestion de mémoire manuelle, fuites mémoires, dangling pointers...).
Le deuxième avantage, c'est la programmation générique. On peut programmer des composants réutilisables sans avoir à utiliser du typage ou du dispatch dynamique.
Les langages de la famille ML se vantent de leur polymorphisme paramétrique et de leurs modules, mais les fonctionnalités pour la programmation générique de C++ (les templates) permettent bien plus de choses, et sont plus faciles à comprendre pour un programmeur proche du système (mais peut-être pas pour un fan de lambda-calcul).
Celle-ci peut toutefois parfois être compliquée si on veut réaliser certaines choses car nécessitant d'exploiter un peu de méta-programmation pour vérifier certaines propriétés sur les types. De bons outils, comme ceux de boost, peuvent toutefois fortement aider.
La programmation générique sera grandement simplifiée par l'introduction en C++0x des concepts. Ceux-ci permettent de vérifier simplement certaines propriétés sur des types, d'une façon similaire à l'héritage, mais de manière non-intrusive (sans que le type soit explicitement défini comme sous-typant un certain autre type -- le sous-typage est implicite).
Certains aspects de la programmation générique resteront toujours complexes et pour les gurus, comme la réalisation d'un DSEL, même si boost.proto aide beaucoup.
L'héritage permet d'avoir du polymorphisme dynamique à la Java, ce qui est souvent synonyme de programmer plus ou moins à la Java, avec des pointeurs dans tous les sens, de la sémantique d'entité et de la gestion de mémoire "globale" (refcounting ou GC).
Bien évidemment, programmer avec l'héritage, une sémantique de valeur et une gestion de mémoire "non globale" peut se faire, mais en pratique ce n'est pas fait.
Les gens adeptes de cette approche, quand ils codent proprement, utilisent alors plutôt shared_ptr.
La mode actuelle vers laquelle se dirige le C++ moderne est cependant de ne pas utiliser l'héritage, mais de préférer le sous-typage implicite non-intrusif, comme les concepts donc, et avec des objets valeurs (qui restent implémentés par des fonctions virtuelles et des templates sous le capôt) .
Un exemple populaire étant function<R (T1... TN)>, qui permet de contenir un objet de n'importe quel type à partir du moment où on peut l'appeler avec la signature choisie. D'autres exemples plus génériques sont boost.any et choses similaires.
Le futur étant quelque chose dans le genre de adobe::poly -- qui a eu quelques publications scientifiques ces derniers temps [1] --, qui permet vraiment d'avoir de la programmation générique comme avec les templates avec du polymorphisme dynamique au lieu du polymorphisme statique qui les caractérise.
L'héritage multiple etc. est vraiment très peu utilisé. Principalement par la programmation par contrats ou par les frameworks fortement orientés objet (comme le sont bien souvent les GUI toolkits).
Donc réellement, les aspects intéressants du C++ sont le RAII et les templates.
Dire que ce sont des fonctionnalités complexes uniquement pour utilisateurs avancés me semble donc une aberration.
Si ces aspects ne sont pas bien connus par la personne, ou pas utilisés, je pense donc que celle-ci passe vraiment à côté de ce qu'est C++.
[1] http://www.emarcus.org/papers/MPOOL2007-marcus.pdf
http://www.emarcus.org/papers/MPOOL2007-slides-marcus.pdf (même chose sous forme de slides)
[^] # Re: gcc lave plus blanc ?
Posté par loufoque . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 4.
Ce n'est nullement la norme. La grammaire n'est qu'une toute petite partie de la définition d'un langage, le plus important c'est la sémantique.
La norme C99+TC1+TC2, elle est là (c'est un working draft, bien sûr, parce que la version finale faut l'acheter) : http://open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf
Elle ne fait que la moitié de la taille du standard C++0x, mais comme je l'ai dit, si tu compares certains passages tu constateras que là où le standard C est flou et pas clair le standard C++ est explicite.
De plus, bon, il parait évident que C++0x est un peu plus compliqué que C99, car ayant plus de fonctionnalités, donc c'est plus long à définir.
Je rappelle que le lien donné précédemment n'est pas C++98, ni C++03, ni C++03+TR1 mais un working draft qui date un peu de C++0x.
D'ailleurs, pour référence, je fournis ces liens :
Draft de C++98 datant de 97 : http://www.open-std.org/jtc1/sc22/open/n2356/
Corrections effectuées en 2003 : http://www.acceleratedcpp.com/authors/koenig/c++std/revision(...)
Dernier working draft de C++0x : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n252(...)
[^] # Re: gcc lave plus blanc ?
Posté par loufoque . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 4.
Au contraire, les adeptes du C++ moderne adorent C++ et n'aiment pas trop Qt.
En effet, Qt n'est pas écrit en C++ mais en C++/MOC, afin d'y rajouter des fonctionnalités qui se font très bien de manière native, de manière plus élégante et surtout de manière type-safe.
De plus, Qt a ses propres conteneurs etc. et donc dédouble une partie importante de choses mieux réalisées par d'autres bibliothèques, en partie la bibliothèque standard.
Et pour finir, utilisation intensive de pointeurs etc., contraire aux idiomes standards de la programmation en C++.
[^] # Re: gcc lave plus blanc ?
Posté par loufoque . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 0.
Et bien C est bien plus court, mais est totalement incompréhensible...
Le fait que le standard C++ soit plus long lui permet d'être clair et précis.
[^] # Re: gcc lave plus blanc ?
Posté par loufoque . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 2.
Pour ce qui est du non-respect des standard, c'est à cause de cela que la plupart des codes ne compilent plus.
Le fait que ça marche à cause d'un comportement erroné ou non documenté du compilateur ne devrait pas être exploité.
[^] # Re: closures
Posté par loufoque . En réponse à la dépêche Sortie de GCC 4.3. Évalué à 1.
Il y a néanmoins tout de même une nouvelle syntaxe plus intuitive pour C++0x, mais pas encore implémentée dans GCC.
[^] # Re: Les mauvaises décisions
Posté par loufoque . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 4.
# llvm-gcc
Posté par loufoque . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
[^] # Re: Parser du C++
Posté par loufoque . En réponse à la dépêche CodeWorker 4.4. Évalué à 1.
Prenons l'expression suivante :
A<b> c;
Si A identifie un template, alors c'est une instanciation de template.
Sinon, c'est une comparaison.
# Parser du C++
Posté par loufoque . En réponse à la dépêche CodeWorker 4.4. Évalué à 8.
Je doute qu'un tel outil en soit capable, étant donné que même le fameux Doxygen n'a qu'un parser C++ approximatif.
[^] # Re: L'ASLR ne sert à rien
Posté par loufoque . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à -4.
De toute façon, cela ne compromet en rien le système.
# L'ASLR ne sert à rien
Posté par loufoque . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à -2.
Ça ne fait que rendre certains bugs plus difficilement exploitables, bugs qui ne devraient pas exister si le programmeur savait utiliser des idiomes sûrs de programmation.
[^] # Re: Public assez mauvais pour la présentation d'Alan Cox
Posté par loufoque . En réponse à la dépêche Les vidéos des rencontres mondiales 2007 en ligne. Évalué à 0.
C'est une présentation. Il est donc impossible de tout dire sur le sujet.
Dans la mesure où ça s'appelle les Rencontres *Mondiales* du Logiciel Libre, maîtriser l'anglais est tout de même un pré-requis évident...
Peut-être qu'on devrait les renommer en Rencontres Franco-Françaises du Logiciel Libre ?
# Public assez mauvais pour la présentation d'Alan Cox
Posté par loufoque . En réponse à la dépêche Les vidéos des rencontres mondiales 2007 en ligne. Évalué à 3.
Il a du insister à plusieurs reprises pour avoir des questions, et a même demandé que lui pose des questions sur n'importe quel sujet et pas nécessairement sur sa présentation.
Alors que, vu le sujet, il y avait de très intéressantes questions à poser, surtout qu'il s'agit d'un développeur assez important du noyau linux.
Ça me fait un peu mal au coeur de voir que le public soit aussi mauvais. Je me demande même ce que les intervenants internationaux doivent penser de la France quand ils voient des interactions pareilles...
[^] # Re: Multicoeur ?
Posté par loufoque . En réponse à la dépêche Intel libère TBB. Évalué à 1.
Chacun sait que les verrous sont une mauvaise façon de gérer la concurrence.
Utilise plutôt du message passing.
[^] # Re: LLVM plus rapide que GCC
Posté par loufoque . En réponse à la dépêche Ouverture du code de CFE, un nouveau frontend C/C++ et sortie de l'infrastructure de compilation LLVM 2.0. Évalué à 1.
http://llvm.org/nightlytest/
Choisis une machine, clique sur "view details", puis sur "full test results", puis regarde la colonne GCC/LLC.
Une valeur supérieure à 1 signfie que LLVM est plus rapide.
De plus, moi qui aime bien regarder l'assembleur généré par mes programmes, je remarque qu'avec LLVM il y a une bien meilleure propagation des constantes et un meilleur inlining.
Ça inline même les fonctions virtuelles... chose dont GCC est incapable.
# LLVM plus rapide que GCC
Posté par loufoque . En réponse à la dépêche Ouverture du code de CFE, un nouveau frontend C/C++ et sortie de l'infrastructure de compilation LLVM 2.0. Évalué à 3.
C'est faux : le code compilé par LLVM est bien plus rapide qu'avec GCC, simplement parce que LLVM fait des optimisatons plus poussées, en particulier à l'édition de liens.
Le format intermédiaire de LLVM, de type SSA, a justement été choisi car il permettait la mise en place des tous derniers algorithmes d'optimisations issus de la recherche.
LLVM a, comme il a été dit dans un autre message, été choisi par le projet Mesa, qui va en faire des backends pour les cartes graphiques modernes. Ce qui signifie qu'à terme on pourra exécuter, en plus de GLSL, du C ou même du Python, le tout optimisé, sur son GPU.
[^] # Re: Concurrence et OpenMP
Posté par loufoque . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 5.
C'est pour cela qu'on a élaboré des modèles sûrs, avec des abstraction de haut niveau, pour la programmation concurrentielle : le message passing surtout, mais aussi un peu les transactions.
On le voit bien avec l'avènement des langages orientés concurrence comme Erlang, Concurrent Haskell, (ou même JOCaml ou C-omega pour les fans du Join-calcul, création française), ou avec des bibliothèques comme CCR (Coordination and
Concurrency Runtime -- truc .NET) ou Intel Threading Building Blocks.
En effet, il est là pour introduire des algorithmes exploitant le parallélisme d'une manière peu élégante.
Ce sont des pragmas, qui sont des sortes de macros.
Donc ce sont plus ou moins des macros. Ce que je voulais dire de toutes façons, c'est que cela ne s'intégrait pas au langage.
"for" est un algorithme.
Je serais fort intéressé de voir un cas où un "for" parallélisé avec OpenMP peut être plus rapide qu'avec une solution sous forme de bibliothèque.
En quoi est-ce plus simple que
parallel_for(blocked_range<int>(0, N), /* code parallèle ici sous forme de fonction */);
deuxième forme qui s'intègre bien mieux dans le langage, bien plus générique par ses aspects fonctionnel et d'intervalle (qui peut fonctionner avec tout type d'itérateur), et qui ressemble fortement à std::for_each ?
(Cet algorithme est disponible tel quel dans Intel Threading Building Blocks)
# Concurrence et OpenMP
Posté par loufoque . En réponse à la dépêche Sortie de GCC 4.2. Évalué à 3.
Les deux sont génériques et peuvent s'appliquer à tous types d'architecture parallèle. Erlang implémente le premier modèle, Haskell le second.
OpenMP n'apporte aucune de ces deux solutions.
La seule chose relativement utile, ce sont ses algorithmes pré-écrits qui exploitent le parallélisme. Algorithmes qui seraient bien mieux sous forme de bibliothèque comme par exemple ceux de la bibliothèque standard de C++, plutôt que sous forme de macros horribles intégrées au langage.