Je crois avoir entendu dire (ici sans doute) qu'un header peut ne pas être un fichier.
Oui.
Quelqu'un pourrait-il, pour ma culture personnelle, me donner un exemple d'environnement de développement où c'est le cas ?
Pas moi.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ <gramster@gramster.com> writes:
Je crois avoir entendu dire (ici sans doute) qu'un header
peut ne pas être un fichier.
Oui.
Quelqu'un pourrait-il, pour ma culture personnelle, me
donner un exemple d'environnement de développement où
c'est le cas ?
Pas moi.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Je crois avoir entendu dire (ici sans doute) qu'un header peut ne pas être un fichier.
Oui.
Quelqu'un pourrait-il, pour ma culture personnelle, me donner un exemple d'environnement de développement où c'est le cas ?
Pas moi.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer
Le 15-01-2006, Fabien LE LEZ a écrit :
Je crois avoir entendu dire (ici sans doute) qu'un header peut ne pas être un fichier.
Quelqu'un pourrait-il, pour ma culture personnelle, me donner un exemple d'environnement de développement où c'est le cas ?
En gcc/C99, j'ai cherché vainement un fichier stdbool.h sur ma machine. Pourtant, #include <stdbool.h> fonctionne comme on s'y attend.
Je ne sais pas à quelle discussion tu fais référence, mais ce que je sais, c'est que le compilo à le droit de ne aller chercher un quelconque fichier quand il voit un #include <...>, mais de faire "comme si".
Marc Boyer -- Entre le fort et le faible, c'est la liberte qui opprime et le droit qui libere. Henri Lacordaire, Dominicain
Le 15-01-2006, Fabien LE LEZ <gramster@gramster.com> a écrit :
Je crois avoir entendu dire (ici sans doute) qu'un header peut ne pas
être un fichier.
Quelqu'un pourrait-il, pour ma culture personnelle, me donner un
exemple d'environnement de développement où c'est le cas ?
En gcc/C99, j'ai cherché vainement un fichier stdbool.h
sur ma machine. Pourtant, #include <stdbool.h> fonctionne
comme on s'y attend.
Je ne sais pas à quelle discussion tu fais référence,
mais ce que je sais, c'est que le compilo à le droit
de ne aller chercher un quelconque fichier quand
il voit un #include <...>, mais de faire "comme si".
Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain
Je crois avoir entendu dire (ici sans doute) qu'un header peut ne pas être un fichier.
Quelqu'un pourrait-il, pour ma culture personnelle, me donner un exemple d'environnement de développement où c'est le cas ?
En gcc/C99, j'ai cherché vainement un fichier stdbool.h sur ma machine. Pourtant, #include <stdbool.h> fonctionne comme on s'y attend.
Je ne sais pas à quelle discussion tu fais référence, mais ce que je sais, c'est que le compilo à le droit de ne aller chercher un quelconque fichier quand il voit un #include <...>, mais de faire "comme si".
Marc Boyer -- Entre le fort et le faible, c'est la liberte qui opprime et le droit qui libere. Henri Lacordaire, Dominicain
kanze
Fabien LE LEZ wrote:
Je crois avoir entendu dire (ici sans doute) qu'un header peut ne pas être un fichier.
Quelqu'un pourrait-il, pour ma culture personnelle, me donner un exemple d'environnement de développement où c'est le cas ?
D'après ce que j'ai entendu dire, Visual Age. Mais je ne suis pas sûr que ce soit le genre d'exemple que tu cherches. La norme dit qu'un en-tête inclu par "..." doit être un fichier. Mais elle ne définit pas « fichier », et d'après j'ai entendu dire, Visual Age garde ses sources en général dans un espèce de base de données.
Sinon, j'ai déjà travaillé (il y a longtemps) avec un compilateur C qui « connaissait » la bibliothèque standard. Il y avait encore des fichiers d'en-tête, mais quand tu faisais #include <stdio.h>, il le gérait différemment que pour un include d'un fichier quelconque.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
Je crois avoir entendu dire (ici sans doute) qu'un header peut
ne pas être un fichier.
Quelqu'un pourrait-il, pour ma culture personnelle, me donner
un exemple d'environnement de développement où c'est le cas ?
D'après ce que j'ai entendu dire, Visual Age. Mais je ne suis
pas sûr que ce soit le genre d'exemple que tu cherches. La norme
dit qu'un en-tête inclu par "..." doit être un fichier. Mais
elle ne définit pas « fichier », et d'après j'ai entendu dire,
Visual Age garde ses sources en général dans un espèce de base
de données.
Sinon, j'ai déjà travaillé (il y a longtemps) avec un
compilateur C qui « connaissait » la bibliothèque standard. Il y
avait encore des fichiers d'en-tête, mais quand tu faisais
#include <stdio.h>, il le gérait différemment que pour un
include d'un fichier quelconque.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Je crois avoir entendu dire (ici sans doute) qu'un header peut ne pas être un fichier.
Quelqu'un pourrait-il, pour ma culture personnelle, me donner un exemple d'environnement de développement où c'est le cas ?
D'après ce que j'ai entendu dire, Visual Age. Mais je ne suis pas sûr que ce soit le genre d'exemple que tu cherches. La norme dit qu'un en-tête inclu par "..." doit être un fichier. Mais elle ne définit pas « fichier », et d'après j'ai entendu dire, Visual Age garde ses sources en général dans un espèce de base de données.
Sinon, j'ai déjà travaillé (il y a longtemps) avec un compilateur C qui « connaissait » la bibliothèque standard. Il y avait encore des fichiers d'en-tête, mais quand tu faisais #include <stdio.h>, il le gérait différemment que pour un include d'un fichier quelconque.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
screetch
Marc Boyer wrote:
Je crois avoir entendu dire (ici sans doute) qu'un header peut ne pas être un fichier.
Quelqu'un pourrait-il, pour ma culture personnelle, me donner un exemple d'environnement de développement où c'est le cas ?
En gcc/C99, j'ai cherché vainement un fichier stdbool.h sur ma machine. Pourtant, #include <stdbool.h> fonctionne comme on s'y attend.
Je ne sais pas à quelle discussion tu fais référence, mais ce que je sais, c'est que le compilo à le droit de ne aller chercher un quelconque fichier quand il voit un #include <...>, mais de faire "comme si".
Marc Boyer MingW :
C:MinGWlibgccmingw323.4.4includestdbool.h sous Linux : /usr/lib/gcc/i486-linux-gnu/4.0.2/include/stdbool.h
Marc Boyer wrote:
Je crois avoir entendu dire (ici sans doute) qu'un header peut ne pas
être un fichier.
Quelqu'un pourrait-il, pour ma culture personnelle, me donner un
exemple d'environnement de développement où c'est le cas ?
En gcc/C99, j'ai cherché vainement un fichier stdbool.h
sur ma machine. Pourtant, #include <stdbool.h> fonctionne
comme on s'y attend.
Je ne sais pas à quelle discussion tu fais référence,
mais ce que je sais, c'est que le compilo à le droit
de ne aller chercher un quelconque fichier quand
il voit un #include <...>, mais de faire "comme si".
Marc Boyer
MingW :
C:MinGWlibgccmingw323.4.4includestdbool.h
sous Linux :
/usr/lib/gcc/i486-linux-gnu/4.0.2/include/stdbool.h
Je crois avoir entendu dire (ici sans doute) qu'un header peut ne pas être un fichier.
Quelqu'un pourrait-il, pour ma culture personnelle, me donner un exemple d'environnement de développement où c'est le cas ?
En gcc/C99, j'ai cherché vainement un fichier stdbool.h sur ma machine. Pourtant, #include <stdbool.h> fonctionne comme on s'y attend.
Je ne sais pas à quelle discussion tu fais référence, mais ce que je sais, c'est que le compilo à le droit de ne aller chercher un quelconque fichier quand il voit un #include <...>, mais de faire "comme si".
Marc Boyer MingW :
C:MinGWlibgccmingw323.4.4includestdbool.h sous Linux : /usr/lib/gcc/i486-linux-gnu/4.0.2/include/stdbool.h
Marc Boyer
Le 16-01-2006, screetch a écrit :
Marc Boyer wrote:
Je crois avoir entendu dire (ici sans doute) qu'un header peut ne pas être un fichier. Quelqu'un pourrait-il, pour ma culture personnelle, me donner un exemple d'environnement de développement où c'est le cas ?
En gcc/C99, j'ai cherché vainement un fichier stdbool.h sur ma machine. Pourtant, #include <stdbool.h> fonctionne comme on s'y attend. Marc Boyer MingW :
C:MinGWlibgccmingw323.4.4includestdbool.h sous Linux : /usr/lib/gcc/i486-linux-gnu/4.0.2/include/stdbool.h
Marc Boyer -- Entre le fort et le faible, c'est la liberte qui opprime et le droit qui libere. Henri Lacordaire, Dominicain
Le 16-01-2006, screetch <screetch@gmail.com> a écrit :
Marc Boyer wrote:
Je crois avoir entendu dire (ici sans doute) qu'un header peut ne pas
être un fichier.
Quelqu'un pourrait-il, pour ma culture personnelle, me donner un
exemple d'environnement de développement où c'est le cas ?
En gcc/C99, j'ai cherché vainement un fichier stdbool.h
sur ma machine. Pourtant, #include <stdbool.h> fonctionne
comme on s'y attend.
Marc Boyer
MingW :
C:MinGWlibgccmingw323.4.4includestdbool.h
sous Linux :
/usr/lib/gcc/i486-linux-gnu/4.0.2/include/stdbool.h
Je crois avoir entendu dire (ici sans doute) qu'un header peut ne pas être un fichier. Quelqu'un pourrait-il, pour ma culture personnelle, me donner un exemple d'environnement de développement où c'est le cas ?
En gcc/C99, j'ai cherché vainement un fichier stdbool.h sur ma machine. Pourtant, #include <stdbool.h> fonctionne comme on s'y attend. Marc Boyer MingW :
C:MinGWlibgccmingw323.4.4includestdbool.h sous Linux : /usr/lib/gcc/i486-linux-gnu/4.0.2/include/stdbool.h
/usr/include n'est pas le seul répertoire inclus par GCC je te conseille de faire ta recherche dans /usr/lib/gcc* aussi.
a ma connaissance gcc n'a pas d'include "magique", au pire il "sait" ouvrir les liens symboliques ce qui est un service linux et pas spécifique GCC. je ne connais pas de compilateur dont les include ne seraient pas des fichiers, encore que ca ne me parait pas complétement aberrant.
gcc -E -v - cette commane te donenra la liste des répertoires ou tu peux trouver les fichiers include.
/usr/include n'est pas le seul répertoire inclus par GCC je te conseille
de faire ta recherche dans /usr/lib/gcc* aussi.
a ma connaissance gcc n'a pas d'include "magique", au pire il "sait"
ouvrir les liens symboliques ce qui est un service linux et pas
spécifique GCC. je ne connais pas de compilateur dont les include ne
seraient pas des fichiers, encore que ca ne me parait pas complétement
aberrant.
gcc -E -v -
cette commane te donenra la liste des répertoires ou tu peux trouver les
fichiers include.
/usr/include n'est pas le seul répertoire inclus par GCC je te conseille de faire ta recherche dans /usr/lib/gcc* aussi.
a ma connaissance gcc n'a pas d'include "magique", au pire il "sait" ouvrir les liens symboliques ce qui est un service linux et pas spécifique GCC. je ne connais pas de compilateur dont les include ne seraient pas des fichiers, encore que ca ne me parait pas complétement aberrant.
gcc -E -v - cette commane te donenra la liste des répertoires ou tu peux trouver les fichiers include.
/usr/include n'est pas le seul répertoire inclus par GCC je te conseille de faire ta recherche dans /usr/lib/gcc* aussi.
En effet, merci.
a ma connaissance gcc n'a pas d'include "magique", au pire il "sait" ouvrir les liens symboliques ce qui est un service linux et pas spécifique GCC. je ne connais pas de compilateur dont les include ne seraient pas des fichiers, encore que ca ne me parait pas complétement aberrant.
Disons que pour stdio.h, ça peut être pénible, mais pour stdbool, je voyais bien un traitement direct par le compilo.
gcc -E -v - cette commane te donenra la liste des répertoires ou tu peux trouver les fichiers include.
OK, merci.
Marc Boyer -- Entre le fort et le faible, c'est la liberte qui opprime et le droit qui libere. Henri Lacordaire, Dominicain
Le 16-01-2006, screetch <screetch@gmail.com> a écrit :
/usr/include n'est pas le seul répertoire inclus par GCC je te conseille
de faire ta recherche dans /usr/lib/gcc* aussi.
En effet, merci.
a ma connaissance gcc n'a pas d'include "magique", au pire il "sait"
ouvrir les liens symboliques ce qui est un service linux et pas
spécifique GCC. je ne connais pas de compilateur dont les include ne
seraient pas des fichiers, encore que ca ne me parait pas complétement
aberrant.
Disons que pour stdio.h, ça peut être pénible, mais pour stdbool,
je voyais bien un traitement direct par le compilo.
gcc -E -v -
cette commane te donenra la liste des répertoires ou tu peux trouver les
fichiers include.
OK, merci.
Marc Boyer
--
Entre le fort et le faible, c'est la liberte qui opprime et le droit
qui libere. Henri Lacordaire, Dominicain
/usr/include n'est pas le seul répertoire inclus par GCC je te conseille de faire ta recherche dans /usr/lib/gcc* aussi.
En effet, merci.
a ma connaissance gcc n'a pas d'include "magique", au pire il "sait" ouvrir les liens symboliques ce qui est un service linux et pas spécifique GCC. je ne connais pas de compilateur dont les include ne seraient pas des fichiers, encore que ca ne me parait pas complétement aberrant.
Disons que pour stdio.h, ça peut être pénible, mais pour stdbool, je voyais bien un traitement direct par le compilo.
gcc -E -v - cette commane te donenra la liste des répertoires ou tu peux trouver les fichiers include.
OK, merci.
Marc Boyer -- Entre le fort et le faible, c'est la liberte qui opprime et le droit qui libere. Henri Lacordaire, Dominicain
screetch
Marc Boyer wrote:
Disons que pour stdio.h, ça peut être pénible, mais pour stdbool, je voyais bien un traitement direct par le compilo. on en est pas loin du tout effectivement, le fichier ne contient que des
directives de préprocesseur. cela pourrait presque etre donné en ligne de commande avec des -D et retirer stdbool.
c'est effectivement le genre de fichier qui pourrait etre inliné dans la ligne de commande générée par gcc pour le preprocesseur :)
Marc Boyer wrote:
Disons que pour stdio.h, ça peut être pénible, mais pour stdbool,
je voyais bien un traitement direct par le compilo.
on en est pas loin du tout effectivement, le fichier ne contient que des
directives de préprocesseur. cela pourrait presque etre donné en ligne
de commande avec des -D et retirer stdbool.
c'est effectivement le genre de fichier qui pourrait etre inliné dans la
ligne de commande générée par gcc pour le preprocesseur :)
Disons que pour stdio.h, ça peut être pénible, mais pour stdbool, je voyais bien un traitement direct par le compilo. on en est pas loin du tout effectivement, le fichier ne contient que des
directives de préprocesseur. cela pourrait presque etre donné en ligne de commande avec des -D et retirer stdbool.
c'est effectivement le genre de fichier qui pourrait etre inliné dans la ligne de commande générée par gcc pour le preprocesseur :)
Fabien LE LEZ
On 16 Jan 2006 01:56:00 -0800, "kanze" :
mais quand tu faisais #include <stdio.h>, il le gérait différemment que pour un include d'un fichier quelconque.
C'est bien le genre d'exemple que je cherchais. Mais je me demandais s'il existe encore de tels compilos.
On 16 Jan 2006 01:56:00 -0800, "kanze" <kanze@gabi-soft.fr>:
mais quand tu faisais
#include <stdio.h>, il le gérait différemment que pour un
include d'un fichier quelconque.
C'est bien le genre d'exemple que je cherchais. Mais je me demandais
s'il existe encore de tels compilos.
mais quand tu faisais #include <stdio.h>, il le gérait différemment que pour un include d'un fichier quelconque.
C'est bien le genre d'exemple que je cherchais. Mais je me demandais s'il existe encore de tels compilos.
kanze
Marc Boyer wrote:
[...]
je ne connais pas de compilateur dont les include ne seraient pas des fichiers, encore que ca ne me parait pas complétement aberrant.
Disons que pour stdio.h, ça peut être pénible, mais pour stdbool, je voyais bien un traitement direct par le compilo.
Je dirais que l'intérêt est même plus élevé pour <stdio.h> (ou <string> ou <vector>). Pas forcément que l'en-tête ne soit pas un fichier, mais qu'il soit traité différemment. Il y a en fait deux intérêts :
-- Même si c'est un fichier, le compilateur peut faire certaines suppositions sur ce qu'il y lit. Par exemple, je me suis servi d'un compilateur qui savait ce que c'était un en-tête standard ; il en avait une liste integrée dans le compilateur. Et il notait bien les fonctions qui étaient déclarées dans un en-tête standard, et les traitait différemment lors de l'optimisation. (Principalement, il savait qu'une fonction déclarée dans un en-tête standard n'utilisait pas de variables globales déclarées dans un en-tête utilisateur, et donc éviter d'assurer la mise à jour de ces variables avant l'appel d'une telle fonction.)
-- On pourrait imaginer un compilateur qui connaît parfaitement <vector> et <string> ; si par exemple j'écris quelque chose comme : static std::string const bidon = "bidon" ; il génèrerait directement la valeur préconstruite en mémoire, sans faire appel au constructeur du tout. Éventuellement, il pourrait en faire autant quand je passe une chaîne constante à une fonction qui veut un std::string.
Il y a en fait deux façons d'y arriver : une, c'est que le compilateur reconnaît <string>, et active ces connaissances integrées quand il le voit. L'autre, c'est qu'il y a bien un fichier d'en-tête, mais qu'il contient quelque chose du genre : __activate_builtin( "string" ) ;
Je crois que la tendance actuelle est de préférer cette dernière solution. C'est au moins ce que j'ai vu dans les compilateurs C++, où on a -- ou avait -- couramment des choses comme : extern void* memcpy( void*, void const*, size_t ) ; #define memcpy __builtin( "memcpy" )
Jusqu'ici, je n'ai pas entendu parler d'un compilateur C++ qui fait des choses pareilles. Je crois même que l'orientation actuelle est de déterminer ce qu'il faut pour que le compilateur en fasse les mêmes optimisations, et de créer des moyens pour qu'on puisse les avoir avec n'importe quelle classe utilisateur en plus.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Marc Boyer wrote:
[...]
je ne connais pas de
compilateur dont les include ne seraient pas des fichiers,
encore que ca ne me parait pas complétement aberrant.
Disons que pour stdio.h, ça peut être pénible, mais pour
stdbool, je voyais bien un traitement direct par le compilo.
Je dirais que l'intérêt est même plus élevé pour <stdio.h> (ou
<string> ou <vector>). Pas forcément que l'en-tête ne soit pas
un fichier, mais qu'il soit traité différemment. Il y a en fait
deux intérêts :
-- Même si c'est un fichier, le compilateur peut faire
certaines suppositions sur ce qu'il y lit. Par exemple, je
me suis servi d'un compilateur qui savait ce que c'était un
en-tête standard ; il en avait une liste integrée dans le
compilateur. Et il notait bien les fonctions qui étaient
déclarées dans un en-tête standard, et les traitait
différemment lors de l'optimisation. (Principalement, il
savait qu'une fonction déclarée dans un en-tête standard
n'utilisait pas de variables globales déclarées dans un
en-tête utilisateur, et donc éviter d'assurer la mise à jour
de ces variables avant l'appel d'une telle fonction.)
-- On pourrait imaginer un compilateur qui connaît parfaitement
<vector> et <string> ; si par exemple j'écris quelque chose
comme :
static std::string const bidon = "bidon" ;
il génèrerait directement la valeur préconstruite en
mémoire, sans faire appel au constructeur du tout.
Éventuellement, il pourrait en faire autant quand je passe
une chaîne constante à une fonction qui veut un std::string.
Il y a en fait deux façons d'y arriver : une, c'est que le
compilateur reconnaît <string>, et active ces connaissances
integrées quand il le voit. L'autre, c'est qu'il y a bien un
fichier d'en-tête, mais qu'il contient quelque chose du
genre :
__activate_builtin( "string" ) ;
Je crois que la tendance actuelle est de préférer cette
dernière solution. C'est au moins ce que j'ai vu dans les
compilateurs C++, où on a -- ou avait -- couramment des
choses comme :
extern void* memcpy( void*, void const*, size_t ) ;
#define memcpy __builtin( "memcpy" )
Jusqu'ici, je n'ai pas entendu parler d'un compilateur C++ qui
fait des choses pareilles. Je crois même que l'orientation
actuelle est de déterminer ce qu'il faut pour que le compilateur
en fasse les mêmes optimisations, et de créer des moyens pour
qu'on puisse les avoir avec n'importe quelle classe utilisateur
en plus.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
je ne connais pas de compilateur dont les include ne seraient pas des fichiers, encore que ca ne me parait pas complétement aberrant.
Disons que pour stdio.h, ça peut être pénible, mais pour stdbool, je voyais bien un traitement direct par le compilo.
Je dirais que l'intérêt est même plus élevé pour <stdio.h> (ou <string> ou <vector>). Pas forcément que l'en-tête ne soit pas un fichier, mais qu'il soit traité différemment. Il y a en fait deux intérêts :
-- Même si c'est un fichier, le compilateur peut faire certaines suppositions sur ce qu'il y lit. Par exemple, je me suis servi d'un compilateur qui savait ce que c'était un en-tête standard ; il en avait une liste integrée dans le compilateur. Et il notait bien les fonctions qui étaient déclarées dans un en-tête standard, et les traitait différemment lors de l'optimisation. (Principalement, il savait qu'une fonction déclarée dans un en-tête standard n'utilisait pas de variables globales déclarées dans un en-tête utilisateur, et donc éviter d'assurer la mise à jour de ces variables avant l'appel d'une telle fonction.)
-- On pourrait imaginer un compilateur qui connaît parfaitement <vector> et <string> ; si par exemple j'écris quelque chose comme : static std::string const bidon = "bidon" ; il génèrerait directement la valeur préconstruite en mémoire, sans faire appel au constructeur du tout. Éventuellement, il pourrait en faire autant quand je passe une chaîne constante à une fonction qui veut un std::string.
Il y a en fait deux façons d'y arriver : une, c'est que le compilateur reconnaît <string>, et active ces connaissances integrées quand il le voit. L'autre, c'est qu'il y a bien un fichier d'en-tête, mais qu'il contient quelque chose du genre : __activate_builtin( "string" ) ;
Je crois que la tendance actuelle est de préférer cette dernière solution. C'est au moins ce que j'ai vu dans les compilateurs C++, où on a -- ou avait -- couramment des choses comme : extern void* memcpy( void*, void const*, size_t ) ; #define memcpy __builtin( "memcpy" )
Jusqu'ici, je n'ai pas entendu parler d'un compilateur C++ qui fait des choses pareilles. Je crois même que l'orientation actuelle est de déterminer ce qu'il faut pour que le compilateur en fasse les mêmes optimisations, et de créer des moyens pour qu'on puisse les avoir avec n'importe quelle classe utilisateur en plus.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
