On Thu, 20 May 2004 17:30:14 +0200, Anthony Fleury wrote:
Pas du tout, et un simple test aurait évité d'attendre la réponse d'une personne exterieure.
Un "simple test" aurait permis de savoir comment se comporte son compilateur. Ce n'est pas tout à fait la même chose, même si ça donne une idée de la réponse.
En effet, enfin comme je parle souvent à tort d'après mon experience, je n'ai jamais vu de compilateur qui avait un comportement autre... Mais je ferai attention à bien préciser ma pensée à l'avenir :-)
Anthony -- "You could be my unintended, choice to live my life extended You should be the one I'll always love, I'll be there as soon as I can But I'm busy mending broken pieces of the life I had before" (C) Muse - Unintended
Fabien LE LEZ wrote:
On Thu, 20 May 2004 17:30:14 +0200, Anthony Fleury
<fleury_anthony@_hotmail_.com> wrote:
Pas du tout, et un simple test aurait évité d'attendre la réponse d'une
personne exterieure.
Un "simple test" aurait permis de savoir comment se comporte son
compilateur. Ce n'est pas tout à fait la même chose, même si ça donne
une idée de la réponse.
En effet, enfin comme je parle souvent à tort d'après mon experience, je
n'ai jamais vu de compilateur qui avait un comportement autre... Mais je
ferai attention à bien préciser ma pensée à l'avenir :-)
Anthony
--
"You could be my unintended, choice to live my life extended
You should be the one I'll always love, I'll be there as soon as I can
But I'm busy mending broken pieces of the life I had before"
(C) Muse - Unintended
On Thu, 20 May 2004 17:30:14 +0200, Anthony Fleury wrote:
Pas du tout, et un simple test aurait évité d'attendre la réponse d'une personne exterieure.
Un "simple test" aurait permis de savoir comment se comporte son compilateur. Ce n'est pas tout à fait la même chose, même si ça donne une idée de la réponse.
En effet, enfin comme je parle souvent à tort d'après mon experience, je n'ai jamais vu de compilateur qui avait un comportement autre... Mais je ferai attention à bien préciser ma pensée à l'avenir :-)
Anthony -- "You could be my unintended, choice to live my life extended You should be the one I'll always love, I'll be there as soon as I can But I'm busy mending broken pieces of the life I had before" (C) Muse - Unintended
Michel Michaud
Dans news:40acfde8$0$20507$, Anthony
Michel Michaud wrote:
Dans news:40acef68$0$21569$, Anthony
Une fonction inline voit sa portée limitée au fichier en cours, donc il faut qu'elle soit définie dans le .h
Pas vraiment il me semble, en tout cas pas pour les fonctions libres où le inline laisse le « external linkage »...
[...]
Dans la norme ok, mais dans la pratique je n'ai vu que des compilateurs qui avaient un comportement qui faisait que inline entrainait static, c'est à dire réduction de la portée de la fonction.
Ça fonctionne comme j'ai décrit avec VC 7.1...
C'est surprenant que ça ne fonctionne pas avec g++ (est-ce la dernière version que tu as essayée ?).
Par ailleurs, je ne sais toujours pas si c'est pareil avec les fonctions membres et static (je suppose que ce n'est pas le cas avec les fonctions libres statiques alors il faudrait vraiment lire la norme... bientôt !).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:40acfde8$0$20507$626a14ce@news.free.fr, Anthony
Michel Michaud wrote:
Dans news:40acef68$0$21569$626a14ce@news.free.fr, Anthony
Une fonction inline voit sa portée limitée au fichier en
cours, donc il faut qu'elle soit définie dans le .h
Pas vraiment il me semble, en tout cas pas pour les fonctions
libres où le inline laisse le « external linkage »...
[...]
Dans la norme ok, mais dans la pratique je n'ai vu que des
compilateurs qui avaient un comportement qui faisait que inline
entrainait static, c'est à dire réduction de la portée de la
fonction.
Ça fonctionne comme j'ai décrit avec VC 7.1...
C'est surprenant que ça ne fonctionne pas avec g++ (est-ce
la dernière version que tu as essayée ?).
Par ailleurs, je ne sais toujours pas si c'est pareil avec
les fonctions membres et static (je suppose que ce n'est
pas le cas avec les fonctions libres statiques alors il
faudrait vraiment lire la norme... bientôt !).
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Une fonction inline voit sa portée limitée au fichier en cours, donc il faut qu'elle soit définie dans le .h
Pas vraiment il me semble, en tout cas pas pour les fonctions libres où le inline laisse le « external linkage »...
[...]
Dans la norme ok, mais dans la pratique je n'ai vu que des compilateurs qui avaient un comportement qui faisait que inline entrainait static, c'est à dire réduction de la portée de la fonction.
Ça fonctionne comme j'ai décrit avec VC 7.1...
C'est surprenant que ça ne fonctionne pas avec g++ (est-ce la dernière version que tu as essayée ?).
Par ailleurs, je ne sais toujours pas si c'est pareil avec les fonctions membres et static (je suppose que ce n'est pas le cas avec les fonctions libres statiques alors il faudrait vraiment lire la norme... bientôt !).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Anthony Fleury
Anthony Fleury wrote:
[...]
À noter que je n'ai jamais testé comeau mais tous ces codes doivent passer sous Comeau bien sûr.
hum je suis endormi !! je confonds avec les templates qui devraient passer avec export. TC++PL page 161 : "la définition d'une fonction inline doit être réalisée dans la portée."
Anthony -- "You could be my unintended, choice to live my life extended You should be the one I'll always love, I'll be there as soon as I can But I'm busy mending broken pieces of the life I had before" (C) Muse - Unintended
Anthony Fleury wrote:
[...]
À noter que je n'ai jamais testé comeau mais tous ces codes doivent passer
sous Comeau bien sûr.
hum je suis endormi !! je confonds avec les templates qui devraient passer
avec export. TC++PL page 161 :
"la définition d'une fonction inline doit être réalisée dans la portée."
Anthony
--
"You could be my unintended, choice to live my life extended
You should be the one I'll always love, I'll be there as soon as I can
But I'm busy mending broken pieces of the life I had before"
(C) Muse - Unintended
À noter que je n'ai jamais testé comeau mais tous ces codes doivent passer sous Comeau bien sûr.
hum je suis endormi !! je confonds avec les templates qui devraient passer avec export. TC++PL page 161 : "la définition d'une fonction inline doit être réalisée dans la portée."
Anthony -- "You could be my unintended, choice to live my life extended You should be the one I'll always love, I'll be there as soon as I can But I'm busy mending broken pieces of the life I had before" (C) Muse - Unintended
Jean-Marc Bourguet
"Michel Michaud" writes:
Je n'ai pas le temps de vérifier ce cas dans la norme, mais à tout le moins, ceci devrait fonctionner :
// A.cpp inline void A() {}
// B.cpp void A();
int main() { A(); }
Non. Il faut avoir une définition dans toute unité où la fonction est utilisée (3.2/3).
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
"Michel Michaud" <mm@gdzid.com> writes:
Je n'ai pas le temps de vérifier ce cas dans la
norme, mais à tout le moins, ceci devrait fonctionner :
// A.cpp
inline void A()
{}
// B.cpp
void A();
int main()
{
A();
}
Non. Il faut avoir une définition dans toute unité où la
fonction est utilisée (3.2/3).
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 n'ai pas le temps de vérifier ce cas dans la norme, mais à tout le moins, ceci devrait fonctionner :
// A.cpp inline void A() {}
// B.cpp void A();
int main() { A(); }
Non. Il faut avoir une définition dans toute unité où la fonction est utilisée (3.2/3).
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
Michel Michaud
Dans news:, Jean-Marc
"Michel Michaud" writes:
Je n'ai pas le temps de vérifier ce cas dans la norme, mais à tout le moins, ceci devrait fonctionner :
// A.cpp inline void A() {}
// B.cpp void A();
int main() { A(); }
Non. Il faut avoir une définition dans toute unité où la fonction est utilisée (3.2/3).
C'est ce que je comprenais aussi jusqu'à récemment. Mais j'ai pris une note disant que ce n'est pas le cas suite à une discussion vue sur un forum (je n'ai pas noté la référence exacte). Y aurait-il une correction à la norme (ou un DR) qui vient changer ce qu'on peut lire à 3.2/3 ?
(ça me ferait plaisir de me tromper, car j'ai pris la note pour dire que je devais corriger ce que mes livres indiquent !)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:g40j8c.kh.ln@news.bourguet.org, Jean-Marc
"Michel Michaud" <mm@gdzid.com> writes:
Je n'ai pas le temps de vérifier ce cas dans la
norme, mais à tout le moins, ceci devrait fonctionner :
// A.cpp
inline void A()
{}
// B.cpp
void A();
int main()
{
A();
}
Non. Il faut avoir une définition dans toute unité où la
fonction est utilisée (3.2/3).
C'est ce que je comprenais aussi jusqu'à récemment. Mais j'ai
pris une note disant que ce n'est pas le cas suite à une
discussion vue sur un forum (je n'ai pas noté la référence
exacte). Y aurait-il une correction à la norme (ou un DR) qui
vient changer ce qu'on peut lire à 3.2/3 ?
(ça me ferait plaisir de me tromper, car j'ai pris la note pour
dire que je devais corriger ce que mes livres indiquent !)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Je n'ai pas le temps de vérifier ce cas dans la norme, mais à tout le moins, ceci devrait fonctionner :
// A.cpp inline void A() {}
// B.cpp void A();
int main() { A(); }
Non. Il faut avoir une définition dans toute unité où la fonction est utilisée (3.2/3).
C'est ce que je comprenais aussi jusqu'à récemment. Mais j'ai pris une note disant que ce n'est pas le cas suite à une discussion vue sur un forum (je n'ai pas noté la référence exacte). Y aurait-il une correction à la norme (ou un DR) qui vient changer ce qu'on peut lire à 3.2/3 ?
(ça me ferait plaisir de me tromper, car j'ai pris la note pour dire que je devais corriger ce que mes livres indiquent !)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Anthony Fleury
Michel Michaud wrote:
Dans news:40acfde8$0$20507$, Anthony
Dans la norme ok, mais dans la pratique je n'ai vu que des compilateurs qui avaient un comportement qui faisait que inline entrainait static, c'est à dire réduction de la portée de la fonction.
Bon j'ai sorti mon exemplaire de la norme qui me sert pas souvent car j'ai pas trop l'habitude de ce genre de documents...
Ça fonctionne comme j'ai décrit avec VC 7.1...
3.2 point 3 : "An inline function shall be defined in every translation unit in which it is used"
Pourquoi cette restriction ??
C'est surprenant que ça ne fonctionne pas avec g++ (est-ce la dernière version que tu as essayée ?).
Ce n'est pas le dernier gcc vu que j'ai besoin de cette version qui a déjà compilé mon noyau... Je testerai avec le dernier quand je récupererai un pc plus puissant car changer gcc me ferai recompiler pas mal de choses et sur un 233 c'est la misère. En tout cas je n'ai jamais eu le comportement de VC7.1 qui me plait pas mal.
Par ailleurs, je ne sais toujours pas si c'est pareil avec les fonctions membres et static (je suppose que ce n'est pas le cas avec les fonctions libres statiques alors il faudrait vraiment lire la norme... bientôt !).
9.4.1 : [note : the rules described in 9.3 apply to static members functions ]
9.3 point 2 : A member function may be defined in its class definition, in which case it is an inline member function (7.1.2) or it may be defined outside of its class definition if it has already been declared but not defined in its class definition.
Il est bien stipulé aussi dans 9.4 que le mot static ne doit apparaitre que dans la déclaration de la fonction ou de la donnée et non dans sa définition.
Quant aux fonctions libres statiques, elles ont le comportement du C c'est à dire qu'elle ont un "internal linkage" tout comme les fonctions inline.
Anthony -- "You could be my unintended, choice to live my life extended You should be the one I'll always love, I'll be there as soon as I can But I'm busy mending broken pieces of the life I had before" (C) Muse - Unintended
Michel Michaud wrote:
Dans news:40acfde8$0$20507$626a14ce@news.free.fr, Anthony
Dans la norme ok, mais dans la pratique je n'ai vu que des
compilateurs qui avaient un comportement qui faisait que inline
entrainait static, c'est à dire réduction de la portée de la
fonction.
Bon j'ai sorti mon exemplaire de la norme qui me sert pas souvent car j'ai
pas trop l'habitude de ce genre de documents...
Ça fonctionne comme j'ai décrit avec VC 7.1...
3.2 point 3 : "An inline function shall be defined in every translation unit
in which it is used"
Pourquoi cette restriction ??
C'est surprenant que ça ne fonctionne pas avec g++ (est-ce
la dernière version que tu as essayée ?).
Ce n'est pas le dernier gcc vu que j'ai besoin de cette version qui a déjà
compilé mon noyau... Je testerai avec le dernier quand je récupererai un pc
plus puissant car changer gcc me ferai recompiler pas mal de choses et sur
un 233 c'est la misère. En tout cas je n'ai jamais eu le comportement de
VC7.1 qui me plait pas mal.
Par ailleurs, je ne sais toujours pas si c'est pareil avec
les fonctions membres et static (je suppose que ce n'est
pas le cas avec les fonctions libres statiques alors il
faudrait vraiment lire la norme... bientôt !).
9.4.1 : [note : the rules described in 9.3 apply to static members
functions ]
9.3 point 2 : A member function may be defined in its class definition, in
which case it is an inline member function (7.1.2) or it may be defined
outside of its class definition if it has already been declared but not
defined in its class definition.
Il est bien stipulé aussi dans 9.4 que le mot static ne doit apparaitre que
dans la déclaration de la fonction ou de la donnée et non dans sa
définition.
Quant aux fonctions libres statiques, elles ont le comportement du C c'est à
dire qu'elle ont un "internal linkage" tout comme les fonctions inline.
Anthony
--
"You could be my unintended, choice to live my life extended
You should be the one I'll always love, I'll be there as soon as I can
But I'm busy mending broken pieces of the life I had before"
(C) Muse - Unintended
Dans la norme ok, mais dans la pratique je n'ai vu que des compilateurs qui avaient un comportement qui faisait que inline entrainait static, c'est à dire réduction de la portée de la fonction.
Bon j'ai sorti mon exemplaire de la norme qui me sert pas souvent car j'ai pas trop l'habitude de ce genre de documents...
Ça fonctionne comme j'ai décrit avec VC 7.1...
3.2 point 3 : "An inline function shall be defined in every translation unit in which it is used"
Pourquoi cette restriction ??
C'est surprenant que ça ne fonctionne pas avec g++ (est-ce la dernière version que tu as essayée ?).
Ce n'est pas le dernier gcc vu que j'ai besoin de cette version qui a déjà compilé mon noyau... Je testerai avec le dernier quand je récupererai un pc plus puissant car changer gcc me ferai recompiler pas mal de choses et sur un 233 c'est la misère. En tout cas je n'ai jamais eu le comportement de VC7.1 qui me plait pas mal.
Par ailleurs, je ne sais toujours pas si c'est pareil avec les fonctions membres et static (je suppose que ce n'est pas le cas avec les fonctions libres statiques alors il faudrait vraiment lire la norme... bientôt !).
9.4.1 : [note : the rules described in 9.3 apply to static members functions ]
9.3 point 2 : A member function may be defined in its class definition, in which case it is an inline member function (7.1.2) or it may be defined outside of its class definition if it has already been declared but not defined in its class definition.
Il est bien stipulé aussi dans 9.4 que le mot static ne doit apparaitre que dans la déclaration de la fonction ou de la donnée et non dans sa définition.
Quant aux fonctions libres statiques, elles ont le comportement du C c'est à dire qu'elle ont un "internal linkage" tout comme les fonctions inline.
Anthony -- "You could be my unintended, choice to live my life extended You should be the one I'll always love, I'll be there as soon as I can But I'm busy mending broken pieces of the life I had before" (C) Muse - Unintended
Gabriel Dos Reis
"Michel Michaud" writes:
| Dans news:40acef68$0$21569$, Anthony | > Michaël Delva wrote: | > | >> J'ai testé ;-) | > | >> Les implémentations des fonctions sont dans le CPP (Example | >> d'une fonction) | >> | >> inline char Base64::Encode(unsigned char uc) | >> { | > | > Une fonction inline voit sa portée limitée au fichier en cours, | > donc il faut qu'elle soit définie dans le .h | | Pas vraiment il me semble, en tout cas pas pour les fonctions | libres où le inline laisse le « external linkage »...
Ce n'est pas ce que dit la norme.
ARM avait une règle différente (celle que tu décris), mais cela a été explicitement changé dans la norme. Mais de toute façon, MS a décidé de donner une autre signification à « inline » et je ne suis pas du tout surpris qu'il en fasse n'importe quoi.
-- Gaby
"Michel Michaud" <mm@gdzid.com> writes:
| Dans news:40acef68$0$21569$626a14ce@news.free.fr, Anthony
| > Michaël Delva wrote:
| >
| >> J'ai testé ;-)
| >
| >> Les implémentations des fonctions sont dans le CPP (Example
| >> d'une fonction)
| >>
| >> inline char Base64::Encode(unsigned char uc)
| >> {
| >
| > Une fonction inline voit sa portée limitée au fichier en cours,
| > donc il faut qu'elle soit définie dans le .h
|
| Pas vraiment il me semble, en tout cas pas pour les fonctions
| libres où le inline laisse le « external linkage »...
Ce n'est pas ce que dit la norme.
ARM avait une règle différente (celle que tu décris), mais cela a été
explicitement changé dans la norme. Mais de toute façon, MS a décidé
de donner une autre signification à « inline » et je ne suis pas du
tout surpris qu'il en fasse n'importe quoi.
| Dans news:40acef68$0$21569$, Anthony | > Michaël Delva wrote: | > | >> J'ai testé ;-) | > | >> Les implémentations des fonctions sont dans le CPP (Example | >> d'une fonction) | >> | >> inline char Base64::Encode(unsigned char uc) | >> { | > | > Une fonction inline voit sa portée limitée au fichier en cours, | > donc il faut qu'elle soit définie dans le .h | | Pas vraiment il me semble, en tout cas pas pour les fonctions | libres où le inline laisse le « external linkage »...
Ce n'est pas ce que dit la norme.
ARM avait une règle différente (celle que tu décris), mais cela a été explicitement changé dans la norme. Mais de toute façon, MS a décidé de donner une autre signification à « inline » et je ne suis pas du tout surpris qu'il en fasse n'importe quoi.
-- Gaby
Gabriel Dos Reis
Anthony Fleury writes:
| Michel Michaud wrote: | | > Dans news:40acef68$0$21569$, Anthony | | >> Une fonction inline voit sa portée limitée au fichier en cours, | >> donc il faut qu'elle soit définie dans le .h | > | > Pas vraiment il me semble, en tout cas pas pour les fonctions | > libres où le inline laisse le « external linkage »... | > | > Mais comme ça ne fonctionne pas pour Michaël, soit ce n'est pas | > le cas pour les fonctions membres, soit son compilateur n'est | > pas à jour. Je n'ai pas le temps de vérifier ce cas dans la | > norme, mais à tout le moins, ceci devrait fonctionner : | > | | Dans la norme ok,
La norme ne dis pas qu'une fonction member statique inline avait un linkage interne. Tout au contraire.
| mais dans la pratique je n'ai vu que des compilateurs qui | avaient un comportement qui faisait que inline entrainait static, c'est à | dire réduction de la portée de la fonction.
CFfront et les compilateurs pré-norme compatibles avec CFront ont ce comportement. C'est ce qui est décrit dans l'ARM. Mais cela a été explicitement changé il y a longtemps.
-- Gaby
Anthony Fleury <fleury_anthony@_hotmail_.com> writes:
| Michel Michaud wrote:
|
| > Dans news:40acef68$0$21569$626a14ce@news.free.fr, Anthony
|
| >> Une fonction inline voit sa portée limitée au fichier en cours,
| >> donc il faut qu'elle soit définie dans le .h
| >
| > Pas vraiment il me semble, en tout cas pas pour les fonctions
| > libres où le inline laisse le « external linkage »...
| >
| > Mais comme ça ne fonctionne pas pour Michaël, soit ce n'est pas
| > le cas pour les fonctions membres, soit son compilateur n'est
| > pas à jour. Je n'ai pas le temps de vérifier ce cas dans la
| > norme, mais à tout le moins, ceci devrait fonctionner :
| >
|
| Dans la norme ok,
La norme ne dis pas qu'une fonction member statique inline avait un linkage
interne. Tout au contraire.
| mais dans la pratique je n'ai vu que des compilateurs qui
| avaient un comportement qui faisait que inline entrainait static, c'est à
| dire réduction de la portée de la fonction.
CFfront et les compilateurs pré-norme compatibles avec CFront ont ce
comportement. C'est ce qui est décrit dans l'ARM. Mais cela a été
explicitement changé il y a longtemps.
| Michel Michaud wrote: | | > Dans news:40acef68$0$21569$, Anthony | | >> Une fonction inline voit sa portée limitée au fichier en cours, | >> donc il faut qu'elle soit définie dans le .h | > | > Pas vraiment il me semble, en tout cas pas pour les fonctions | > libres où le inline laisse le « external linkage »... | > | > Mais comme ça ne fonctionne pas pour Michaël, soit ce n'est pas | > le cas pour les fonctions membres, soit son compilateur n'est | > pas à jour. Je n'ai pas le temps de vérifier ce cas dans la | > norme, mais à tout le moins, ceci devrait fonctionner : | > | | Dans la norme ok,
La norme ne dis pas qu'une fonction member statique inline avait un linkage interne. Tout au contraire.
| mais dans la pratique je n'ai vu que des compilateurs qui | avaient un comportement qui faisait que inline entrainait static, c'est à | dire réduction de la portée de la fonction.
CFfront et les compilateurs pré-norme compatibles avec CFront ont ce comportement. C'est ce qui est décrit dans l'ARM. Mais cela a été explicitement changé il y a longtemps.
-- Gaby
Gabriel Dos Reis
"Michel Michaud" writes:
[...]
| > Dans la norme ok, mais dans la pratique je n'ai vu que des | > compilateurs qui avaient un comportement qui faisait que inline | > entrainait static, c'est à dire réduction de la portée de la | > fonction. | | Ça fonctionne comme j'ai décrit avec VC 7.1...
oui mais non.
| C'est surprenant que ça ne fonctionne pas avec g++
Parce que g++ implémente ce qu'exige la norme sur ce point. C'est effectivement étrange d'implémenter ce que la norme stipule, d'ailleurs je ne comprends pas pourquoi on a une norme.
-- Gaby
"Michel Michaud" <mm@gdzid.com> writes:
[...]
| > Dans la norme ok, mais dans la pratique je n'ai vu que des
| > compilateurs qui avaient un comportement qui faisait que inline
| > entrainait static, c'est à dire réduction de la portée de la
| > fonction.
|
| Ça fonctionne comme j'ai décrit avec VC 7.1...
oui mais non.
| C'est surprenant que ça ne fonctionne pas avec g++
Parce que g++ implémente ce qu'exige la norme sur ce point.
C'est effectivement étrange d'implémenter ce que la norme stipule,
d'ailleurs je ne comprends pas pourquoi on a une norme.
| > Dans la norme ok, mais dans la pratique je n'ai vu que des | > compilateurs qui avaient un comportement qui faisait que inline | > entrainait static, c'est à dire réduction de la portée de la | > fonction. | | Ça fonctionne comme j'ai décrit avec VC 7.1...
oui mais non.
| C'est surprenant que ça ne fonctionne pas avec g++
Parce que g++ implémente ce qu'exige la norme sur ce point. C'est effectivement étrange d'implémenter ce que la norme stipule, d'ailleurs je ne comprends pas pourquoi on a une norme.
-- Gaby
Gabriel Dos Reis
Anthony Fleury writes:
[...]
| 3.2 point 3 : "An inline function shall be defined in every translation unit | in which it is used" | | Pourquoi cette restriction ??
Il faut une exigence quelque part. Oui bien tu la mets sur l'utilisateur ou bien tu la mets sur l'implémenteur (ou parfois les deux). Cela demande plus d'infrastructure d'inliner trans uniter de traduction que d'avoir le corps disponible dans chaque unité de traduction. Si tu demandes trop de travail aux implémenteurs, ils ne feront qu'à leurs têtes et il peut arriver qu'ils fassent n'importe quoi. Et que tu n'aies pas la fonctionnalité que tu veux. Alors, tu demandes un peu d'effort de la part de l'utilisateur. N'oublie pas, « inline » a été introduit en C with Classes vers 1981 avec l'exigence que ce soit utile ici et maintenant. 25 ans plus tard, peu de progrès ont été faits :-(
| | > | > C'est surprenant que ça ne fonctionne pas avec g++ (est-ce | > la dernière version que tu as essayée ?). | > | | Ce n'est pas le dernier gcc vu que j'ai besoin de cette version qui a déjà | compilé mon noyau... Je testerai avec le dernier quand je récupererai un pc
C'est pas la peine. GCC fait comme la norme demande que ça se passe.
-- Gaby
Anthony Fleury <fleury_anthony@_hotmail_.com> writes:
[...]
| 3.2 point 3 : "An inline function shall be defined in every translation unit
| in which it is used"
|
| Pourquoi cette restriction ??
Il faut une exigence quelque part. Oui bien tu la mets sur
l'utilisateur ou bien tu la mets sur l'implémenteur (ou parfois les
deux). Cela demande plus d'infrastructure d'inliner trans uniter de
traduction que d'avoir le corps disponible dans chaque unité de
traduction. Si tu demandes trop de travail aux implémenteurs, ils ne
feront qu'à leurs têtes et il peut arriver qu'ils fassent n'importe
quoi. Et que tu n'aies pas la fonctionnalité que tu veux.
Alors, tu demandes un peu d'effort de la part de l'utilisateur.
N'oublie pas, « inline » a été introduit en C with Classes vers 1981
avec l'exigence que ce soit utile ici et maintenant. 25 ans plus tard,
peu de progrès ont été faits :-(
|
| >
| > C'est surprenant que ça ne fonctionne pas avec g++ (est-ce
| > la dernière version que tu as essayée ?).
| >
|
| Ce n'est pas le dernier gcc vu que j'ai besoin de cette version qui a déjà
| compilé mon noyau... Je testerai avec le dernier quand je récupererai un pc
C'est pas la peine. GCC fait comme la norme demande que ça se passe.
| 3.2 point 3 : "An inline function shall be defined in every translation unit | in which it is used" | | Pourquoi cette restriction ??
Il faut une exigence quelque part. Oui bien tu la mets sur l'utilisateur ou bien tu la mets sur l'implémenteur (ou parfois les deux). Cela demande plus d'infrastructure d'inliner trans uniter de traduction que d'avoir le corps disponible dans chaque unité de traduction. Si tu demandes trop de travail aux implémenteurs, ils ne feront qu'à leurs têtes et il peut arriver qu'ils fassent n'importe quoi. Et que tu n'aies pas la fonctionnalité que tu veux. Alors, tu demandes un peu d'effort de la part de l'utilisateur. N'oublie pas, « inline » a été introduit en C with Classes vers 1981 avec l'exigence que ce soit utile ici et maintenant. 25 ans plus tard, peu de progrès ont été faits :-(
| | > | > C'est surprenant que ça ne fonctionne pas avec g++ (est-ce | > la dernière version que tu as essayée ?). | > | | Ce n'est pas le dernier gcc vu que j'ai besoin de cette version qui a déjà | compilé mon noyau... Je testerai avec le dernier quand je récupererai un pc
C'est pas la peine. GCC fait comme la norme demande que ça se passe.
