Plus couramment, ce serait un truc :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14 // f.h inline int func() { return 3; } // unit1.cpp #include "f.h" // unit2.cpp #include "f.h"
Version imprimable
Plus couramment, ce serait un truc :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14 // f.h inline int func() { return 3; } // unit1.cpp #include "f.h" // unit2.cpp #include "f.h"
Oui, c'est l'utilisation habituelle.
ainsi que
Code:
1
2
3
4
5
6 // unit1.cpp inline int func() { return 3; }
non? enfin c'est juste pour être sur d'avoir compris. Du coup la fonction utilisée dans unit1.cpp et unit2.cpp seront différente?Code:
1
2
3
4
5
6
7 // unit2.cpp inline int func() { return 5; }
Et sans le inline? cela donne une erreur de link car définition multiple?
Sans inline, définition multiple, erreur au link.
Avec inline, aucun diagnostic n'est requis, mais tu violes la one definition rule.
:oops: sorry. mais ça compilera avec les inline...
et avec les template??
Code:
1
2
3
4
5
6
7 //AA.h template <typename T> struct AA { T test(); }
Code:
1
2
3
4
5
6
7
8
9 // unit1.cpp #include "AA.h" inline template <typename T> T AA::test() { return static_cast<T>(3); }
Code:
1
2
3
4
5
6
7
8
9 // unit2.cpp #include "AA.h" inline template <typename T> T AA::test() { return static_cast<T>(5); }
Et en les déclarant static en plus de inline ?Citation:
Envoyé par JolyLoic
Si elles sont statiques, il s'agit de deux fonctions différentes, qui n'ont aucun lien entre elles. Qu'elles soient inline ou pas.
OK. Donc, pour le standard, les fonctions inline ne sont pas implicitement statiques.
Contrairement au comportement du compilateur de Microsoft... Encore que le "unless otherwise specified" me laisse des doutes...
Citation:
Envoyé par [url=http://msdn2.microsoft.com/en-us/library/z8y1yy88(VS.80).aspx]MSDN[/url]
C'est sans doute parce que tu as une préséence au niveau des storage class specifiers (static, extern et autres) qui peut venir chambouler la portée de la liaison ;)
Si j'ai bonne memoire, un des effets de l'implementation d'export dans EDG c'est que ca l'a rendu capable de diagnostiquer certaines violations de l'ODR. Je suppose que c'est un effet possible aussi de l'implementation d'optimisation globale (au minimum ca doit faire des choses "amusantes" avec les programmes qui violent l'ODR).
Pour des tests assez profonds de l'ODR, je devine en effet que l'implémentation d'export puisse aider, en ce qu'elle impose de clarifier le contexte de définition de la fonction.
Par contre, pour des cas bêtes comme on a pu citer ici, je pense que la condition : "each definition of D shall consist of the same sequence of tokens;" pourrait être détectée assez trivialement, lors par exemple de l'optimisation globale.
Effectivement, je dois mélanger avec quelque chose d'autre.Citation:
Un typedef ne crée aucune instance du template.
Je vous remerci pour vos réponses mais vous vous eloignés quelque peu du sujet.
Personne donc n'aurai d'idée ?
Le problème devrait venir du compilateur lui-même s'il n'y a pas d'erreur avec VC2005.
Est-ce que quelqu'un a déja réussi à compiler quelque chose de similaire ou pas, sous VC6 ?
Merci.
Du coup, j'ai installer VC2005 express et compilé le même code avec. Le compilateur de trouve aucune erreur et le programme marche sans bug.
J'en conclu donc que le problème proviens de VC6. Je vais être obligé de changer de compilo.
Bref. Merci à vous tous de m'avoir répondu.
A une prochaine. ;)
Si tu ne le savais pas déjà, VC6 est loin de coller à la norme du C++, particulièrement en ce qui concerne les templates, par exemple.