Je me remets à C++ après quelques années de Python intensif, et c'est
dur, je suis très rouillé...
J'essaie de comprendre et de traduire en C++ le premier programme décrit
à la page http://www.dofactory.com/Patterns/PatternAbstract.aspx mais,
à l'exécution, j'obtiens (j'ai rajouté quelques autres affichages par
rapport à l'exemple) :
Env received 16ConcreteFactory1 as factory.
Env creating Product 16AbstractProductA
Env creating Product 9ProductB1
P9ProductB1 interacts with P16AbstractProductA
In Environment, 16AbstractProductA interacts with 9ProductB1
Env received 16ConcreteFactory2 as factory.
Env creating Product 16AbstractProductA
Env creating Product 9ProductB2
9ProductB2 interacts with 16AbstractProductA
In Environment, 16AbstractProductA interacts with 9ProductB2
(avec g++ 3.4)
alors que normalement je m'attends d'après l'exemple à avoir des
ProductA1 ou ProductA2 à la place des AbstractProductA.
Le plus bizarre c'est que le schéma Factory semble bien fonctionner avec
les produits B et pas avec les produits A.
Je ne vois pas trop ce que je rate, mais c'est sans doute tout simple...
Sinon une autre question : pourquoi la fonction typeid(variable).name()
ne donne-t-elle pas un type de classe ou de variable bien propre comme
dans la plupart des docs mais rajoute quelques chiffres ? Par exemple,
pourquoi obtiens-je "9ProductB1" à la place de "ProductB1" ?
Mon code :
----------------------------------------------------------------------
#include<iostream>
using namespace std;
#include<typeinfo>
class AbstractProductB
{
public:
// Methods
virtual void Interact( AbstractProductA* a )=0;
};
// "ProductA1"
class ProductA1 : public AbstractProductA
{
int a1;
};
// "ProductB1"
class ProductB1 : public AbstractProductB
{
public:
// Methods
virtual void Interact( AbstractProductA* a ) //const
{
//Console.WriteLine( this + " interacts with " + a );
cout<<typeid(this).name()<<" interacts with "<< typeid(a).name() << endl;
}
};
// "ProductA2"
class ProductA2 : public AbstractProductA
{
int a2;
};
// "ProductB2"
class ProductB2 : public AbstractProductB
{
public:
// Methods
virtual void Interact( AbstractProductA* a )
{
//Console.WriteLine( this + " interacts with " + a );
cout<<typeid(*this).name()<<" interacts with "<< typeid(*a).name() << endl;
}
};
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Ahmed MOHAMED ALI
Bonsoir,
Je me remets à C++ après quelques années de Python intensif, et c'est dur, je suis très rouillé...
Je serai curieux de savoir ce qui te fait passer de python à C++.
alors que normalement je m'attends d'après l'exemple à avoir des ProductA1 ou ProductA2 à la place des AbstractProductA.
Le plus bizarre c'est que le schéma Factory semble bien fonctionner avec les produits B et pas avec les produits A.
La différence de comportement s'explique par le fait que les produits B sont polymorphiques alors que les produits A ne le sont pas. (AbstractProductA ne comporte aucune méthode virtuelle alors que AbstractProductB en possède une.)
Sinon une autre question : pourquoi la fonction typeid(variable).name() ne donne-t-elle pas un type de classe ou de variable bien propre comme dans la plupart des docs mais rajoute quelques chiffres ? Par exemple, pourquoi obtiens-je "9ProductB1" à la place de "ProductB1" ?
Je ne sais pas ce que tu entends par "la plupart des docs" mais je pense que le comportement de typeid(...).name() n'est pas standard.Les implémentations doivent garantir l'unicité du nom à priori.Encore que là, il faut voir ce qui se passe entre différentes compilations.
Ahmed MOHAMEDALI
"Damien Wyart" wrote in message news:426eb5c1$0$19270$
Bonsoir,
Je me remets à C++ après quelques années de Python intensif, et c'est dur, je suis très rouillé...
J'essaie de comprendre et de traduire en C++ le premier programme décrit à la page http://www.dofactory.com/Patterns/PatternAbstract.aspx mais, à l'exécution, j'obtiens (j'ai rajouté quelques autres affichages par rapport à l'exemple) :
Env received 16ConcreteFactory1 as factory. Env creating Product 16AbstractProductA Env creating Product 9ProductB1 P9ProductB1 interacts with P16AbstractProductA In Environment, 16AbstractProductA interacts with 9ProductB1 Env received 16ConcreteFactory2 as factory. Env creating Product 16AbstractProductA Env creating Product 9ProductB2 9ProductB2 interacts with 16AbstractProductA In Environment, 16AbstractProductA interacts with 9ProductB2
(avec g++ 3.4)
alors que normalement je m'attends d'après l'exemple à avoir des ProductA1 ou ProductA2 à la place des AbstractProductA.
Le plus bizarre c'est que le schéma Factory semble bien fonctionner avec les produits B et pas avec les produits A.
Je ne vois pas trop ce que je rate, mais c'est sans doute tout simple...
Sinon une autre question : pourquoi la fonction typeid(variable).name() ne donne-t-elle pas un type de classe ou de variable bien propre comme dans la plupart des docs mais rajoute quelques chiffres ? Par exemple, pourquoi obtiens-je "9ProductB1" à la place de "ProductB1" ?
Mon code :
---------------------------------------------------------------------- #include<iostream> using namespace std; #include<typeinfo>
class AbstractProductB { public: // Methods virtual void Interact( AbstractProductA* a )=0; };
// "ProductA1"
class ProductA1 : public AbstractProductA { int a1; };
// "ProductB1"
class ProductB1 : public AbstractProductB { public: // Methods virtual void Interact( AbstractProductA* a ) //const { //Console.WriteLine( this + " interacts with " + a ); cout<<typeid(this).name()<<" interacts with "<< typeid(a).name() << endl;
} };
// "ProductA2"
class ProductA2 : public AbstractProductA { int a2; };
// "ProductB2"
class ProductB2 : public AbstractProductB { public: // Methods virtual void Interact( AbstractProductA* a ) { //Console.WriteLine( this + " interacts with " + a ); cout<<typeid(*this).name()<<" interacts with "<< typeid(*a).name() << endl;
Je me remets à C++ après quelques années de Python intensif, et c'est
dur, je suis très rouillé...
Je serai curieux de savoir ce qui te fait passer de python à C++.
alors que normalement je m'attends d'après l'exemple à avoir des
ProductA1 ou ProductA2 à la place des AbstractProductA.
Le plus bizarre c'est que le schéma Factory semble bien fonctionner avec
les produits B et pas avec les produits A.
La différence de comportement s'explique par le fait que les produits B sont
polymorphiques alors que les produits A ne le sont pas.
(AbstractProductA ne comporte aucune méthode virtuelle alors que
AbstractProductB en possède une.)
Sinon une autre question : pourquoi la fonction typeid(variable).name()
ne donne-t-elle pas un type de classe ou de variable bien propre comme
dans la plupart des docs mais rajoute quelques chiffres ? Par exemple,
pourquoi obtiens-je "9ProductB1" à la place de "ProductB1" ?
Je ne sais pas ce que tu entends par "la plupart des docs" mais je pense que
le comportement de typeid(...).name() n'est pas
standard.Les implémentations doivent garantir l'unicité du nom à
priori.Encore que là, il faut voir ce qui se passe entre différentes
compilations.
Ahmed MOHAMEDALI
"Damien Wyart" <damien.wyart@free.fr> wrote in message
news:426eb5c1$0$19270$636a15ce@news.free.fr...
Bonsoir,
Je me remets à C++ après quelques années de Python intensif, et c'est
dur, je suis très rouillé...
J'essaie de comprendre et de traduire en C++ le premier programme décrit
à la page http://www.dofactory.com/Patterns/PatternAbstract.aspx mais,
à l'exécution, j'obtiens (j'ai rajouté quelques autres affichages par
rapport à l'exemple) :
Env received 16ConcreteFactory1 as factory.
Env creating Product 16AbstractProductA
Env creating Product 9ProductB1
P9ProductB1 interacts with P16AbstractProductA
In Environment, 16AbstractProductA interacts with 9ProductB1
Env received 16ConcreteFactory2 as factory.
Env creating Product 16AbstractProductA
Env creating Product 9ProductB2
9ProductB2 interacts with 16AbstractProductA
In Environment, 16AbstractProductA interacts with 9ProductB2
(avec g++ 3.4)
alors que normalement je m'attends d'après l'exemple à avoir des
ProductA1 ou ProductA2 à la place des AbstractProductA.
Le plus bizarre c'est que le schéma Factory semble bien fonctionner avec
les produits B et pas avec les produits A.
Je ne vois pas trop ce que je rate, mais c'est sans doute tout simple...
Sinon une autre question : pourquoi la fonction typeid(variable).name()
ne donne-t-elle pas un type de classe ou de variable bien propre comme
dans la plupart des docs mais rajoute quelques chiffres ? Par exemple,
pourquoi obtiens-je "9ProductB1" à la place de "ProductB1" ?
Mon code :
----------------------------------------------------------------------
#include<iostream>
using namespace std;
#include<typeinfo>
class AbstractProductB
{
public:
// Methods
virtual void Interact( AbstractProductA* a )=0;
};
// "ProductA1"
class ProductA1 : public AbstractProductA
{
int a1;
};
// "ProductB1"
class ProductB1 : public AbstractProductB
{
public:
// Methods
virtual void Interact( AbstractProductA* a ) //const
{
//Console.WriteLine( this + " interacts with " + a );
cout<<typeid(this).name()<<" interacts with "<< typeid(a).name() <<
endl;
}
};
// "ProductA2"
class ProductA2 : public AbstractProductA
{
int a2;
};
// "ProductB2"
class ProductB2 : public AbstractProductB
{
public:
// Methods
virtual void Interact( AbstractProductA* a )
{
//Console.WriteLine( this + " interacts with " + a );
cout<<typeid(*this).name()<<" interacts with "<< typeid(*a).name() <<
endl;
Je me remets à C++ après quelques années de Python intensif, et c'est dur, je suis très rouillé...
Je serai curieux de savoir ce qui te fait passer de python à C++.
alors que normalement je m'attends d'après l'exemple à avoir des ProductA1 ou ProductA2 à la place des AbstractProductA.
Le plus bizarre c'est que le schéma Factory semble bien fonctionner avec les produits B et pas avec les produits A.
La différence de comportement s'explique par le fait que les produits B sont polymorphiques alors que les produits A ne le sont pas. (AbstractProductA ne comporte aucune méthode virtuelle alors que AbstractProductB en possède une.)
Sinon une autre question : pourquoi la fonction typeid(variable).name() ne donne-t-elle pas un type de classe ou de variable bien propre comme dans la plupart des docs mais rajoute quelques chiffres ? Par exemple, pourquoi obtiens-je "9ProductB1" à la place de "ProductB1" ?
Je ne sais pas ce que tu entends par "la plupart des docs" mais je pense que le comportement de typeid(...).name() n'est pas standard.Les implémentations doivent garantir l'unicité du nom à priori.Encore que là, il faut voir ce qui se passe entre différentes compilations.
Ahmed MOHAMEDALI
"Damien Wyart" wrote in message news:426eb5c1$0$19270$
Bonsoir,
Je me remets à C++ après quelques années de Python intensif, et c'est dur, je suis très rouillé...
J'essaie de comprendre et de traduire en C++ le premier programme décrit à la page http://www.dofactory.com/Patterns/PatternAbstract.aspx mais, à l'exécution, j'obtiens (j'ai rajouté quelques autres affichages par rapport à l'exemple) :
Env received 16ConcreteFactory1 as factory. Env creating Product 16AbstractProductA Env creating Product 9ProductB1 P9ProductB1 interacts with P16AbstractProductA In Environment, 16AbstractProductA interacts with 9ProductB1 Env received 16ConcreteFactory2 as factory. Env creating Product 16AbstractProductA Env creating Product 9ProductB2 9ProductB2 interacts with 16AbstractProductA In Environment, 16AbstractProductA interacts with 9ProductB2
(avec g++ 3.4)
alors que normalement je m'attends d'après l'exemple à avoir des ProductA1 ou ProductA2 à la place des AbstractProductA.
Le plus bizarre c'est que le schéma Factory semble bien fonctionner avec les produits B et pas avec les produits A.
Je ne vois pas trop ce que je rate, mais c'est sans doute tout simple...
Sinon une autre question : pourquoi la fonction typeid(variable).name() ne donne-t-elle pas un type de classe ou de variable bien propre comme dans la plupart des docs mais rajoute quelques chiffres ? Par exemple, pourquoi obtiens-je "9ProductB1" à la place de "ProductB1" ?
Mon code :
---------------------------------------------------------------------- #include<iostream> using namespace std; #include<typeinfo>
class AbstractProductB { public: // Methods virtual void Interact( AbstractProductA* a )=0; };
// "ProductA1"
class ProductA1 : public AbstractProductA { int a1; };
// "ProductB1"
class ProductB1 : public AbstractProductB { public: // Methods virtual void Interact( AbstractProductA* a ) //const { //Console.WriteLine( this + " interacts with " + a ); cout<<typeid(this).name()<<" interacts with "<< typeid(a).name() << endl;
} };
// "ProductA2"
class ProductA2 : public AbstractProductA { int a2; };
// "ProductB2"
class ProductB2 : public AbstractProductB { public: // Methods virtual void Interact( AbstractProductA* a ) { //Console.WriteLine( this + " interacts with " + a ); cout<<typeid(*this).name()<<" interacts with "<< typeid(*a).name() << endl;
Je me remets à C++ après quelques années de Python intensif, et c'est dur, je suis très rouillé...
Je serai curieux de savoir ce qui te fait passer de python à C++.
Les deux langages s'adressent à de différents domaines d'application, je crois. Python, c'est un langage de script ; il est hors question de s'en servir pour la majorité de mes applications. En revanche, pour les petits boulots d'appoint, il ne me vient pas à l'ésprit de me lancer dans toutes les complexités de la compilation et des fichiers make.
alors que normalement je m'attends d'après l'exemple à avoir des ProductA1 ou ProductA2 à la place des AbstractProductA.
Le plus bizarre c'est que le schéma Factory semble bien fonctionner avec les produits B et pas avec les produits A.
La différence de comportement s'explique par le fait que les produits B sont polymorphiques alors que les produits A ne le sont pas. (AbstractProductA ne comporte aucune méthode virtuelle alors que AbstractProductB en possède une.)
Tout à fait. La norme dit que typeid ne donne le type dynamique que si l'objet est polymorphe. Pour être polymorphe, il faut que l'objet soit de type classe, et que la classe comporte au moins une fonction virtuelle.
Sinon une autre question : pourquoi la fonction typeid(variable).name() > ne donne-t-elle pas un type de
classe ou de variable bien propre comme > dans la plupart des docs mais rajoute quelques chiffres ? Par exemple, > pourquoi obtiens-je "9ProductB1" à la place de "ProductB1" ?
Je ne sais pas ce que tu entends par "la plupart des docs" mais je pense que le comportement de typeid(...).name() n'est pas standard. Les implémentations doivent garantir l'unicité du nom à priori.
Même pas. Il y a eu une proposition de normaliser la chaîne renvoyée, mais elle n'a pas aboutie.
Note bien aussi qu'il y a une tension entre le désir de renvoyer un nom clair et compréhensible pour l'utilisateur, et le désir de renvoyer un nom unique -- pense à des classes dans l'espace référentiel anonyme, ou locales à une fonction, par exemple. En général, vue que dans l'absence d'une normalisation, à peu près la seule chose qu'on peut en faire, c'est de l'afficher, d'un point de vue « qualité d'implémentation », un nom en clair s'impose, d'autant plus qu'on peut le rendre unique à peu de prix dans la plupart des cas (et je crois qu'on accepterait des caractères en plus dans l'espace de nommage anonyme, ou pour des classes locales -- la proposition dont j'ai parlé précédait les espaces référentiels anonymes, mais elle traitait bien le cas des classes locales).
Malheureusement, certaines implémentations ont pris le chemin de la paresse, et sort le nom décoré, tel qu'il apparaît internalement dans le compilateur, et qu'il est passé au linker. Un tel choix ne peut se justifier que dans les cas où il est imposé par une API bien définie pour le C++ sur la plateforme -- c'est le cas de l'architecture IA-64 d'Intel, je crois, mais d'aucune autre plateforme à ma connaissance. (On pourrait aussi poser la question sur le choix dans l'API. Mais ce n'est plus la faute des auteurs du compilateur, qui sont bien obligé de s'aligner.)
Encore que là, il faut voir ce qui se passe entre différentes compilations.
Dans la pratique, ça m'étonne que tu rétrouves les mêmes noms pour des classes définies dans l'espace référentiel anonyme. La plupart des compilateurs (enfin, je crois -- la plupart dont je me sers, en tout cas) génère un nouveau nom interne pour cet espace à chaque compilation. Ce qui pose aussi parfois des problèmes pour les compilateurs qui se servent des répositoires pour les templates. Dans la pratique, j'ai du remplacer un certain nombre d'espaces anonyme par des espaces nommés (du genre « namespace <nomDuFichier>_Private ») ; jusqu'ici, je pourrais dire que c'était pour contourner les défauts du compilateur, mais si je voulais utiliser les typeid().name() comme clé externe quelque part, il me le faudrait aussi, même dans défaut de compilateur.
Seulement, évidemment, dans la mésure où les noms générés ne sont pas garanti unique, et qu'ils varient d'un compilateur à l'autre, je préfère encore utiliser mes propres noms, avec du code que j'ai écris à la main. C'est plus de travail, mais au moins, je sais que ça marchera partout.
-- 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
Ahmed MOHAMED ALI wrote:
Je me remets à C++ après quelques années de Python intensif,
et c'est dur, je suis très rouillé...
Je serai curieux de savoir ce qui te fait passer de python à
C++.
Les deux langages s'adressent à de différents domaines
d'application, je crois. Python, c'est un langage de script ; il
est hors question de s'en servir pour la majorité de mes
applications. En revanche, pour les petits boulots d'appoint, il
ne me vient pas à l'ésprit de me lancer dans toutes les
complexités de la compilation et des fichiers make.
alors que normalement je m'attends d'après l'exemple à avoir
des ProductA1 ou ProductA2 à la place des AbstractProductA.
Le plus bizarre c'est que le schéma Factory semble bien
fonctionner avec les produits B et pas avec les produits A.
La différence de comportement s'explique par le fait que les
produits B sont polymorphiques alors que les produits A ne le
sont pas. (AbstractProductA ne comporte aucune méthode
virtuelle alors que AbstractProductB en possède une.)
Tout à fait. La norme dit que typeid ne donne le type dynamique
que si l'objet est polymorphe. Pour être polymorphe, il faut que
l'objet soit de type classe, et que la classe comporte au moins
une fonction virtuelle.
Sinon une autre question : pourquoi la fonction
typeid(variable).name() > ne donne-t-elle pas un type de
classe ou de variable bien propre comme > dans la plupart des
docs mais rajoute quelques chiffres ? Par exemple, > pourquoi
obtiens-je "9ProductB1" à la place de "ProductB1" ?
Je ne sais pas ce que tu entends par "la plupart des docs"
mais je pense que le comportement de typeid(...).name() n'est
pas standard. Les implémentations doivent garantir l'unicité
du nom à priori.
Même pas. Il y a eu une proposition de normaliser la chaîne
renvoyée, mais elle n'a pas aboutie.
Note bien aussi qu'il y a une tension entre le désir de renvoyer
un nom clair et compréhensible pour l'utilisateur, et le désir
de renvoyer un nom unique -- pense à des classes dans l'espace
référentiel anonyme, ou locales à une fonction, par
exemple. En général, vue que dans l'absence d'une normalisation,
à peu près la seule chose qu'on peut en faire, c'est de
l'afficher, d'un point de vue « qualité d'implémentation », un
nom en clair s'impose, d'autant plus qu'on peut le rendre unique
à peu de prix dans la plupart des cas (et je crois qu'on
accepterait des caractères en plus dans l'espace de nommage
anonyme, ou pour des classes locales -- la proposition dont j'ai
parlé précédait les espaces référentiels anonymes, mais elle
traitait bien le cas des classes locales).
Malheureusement, certaines implémentations ont pris le chemin de
la paresse, et sort le nom décoré, tel qu'il apparaît
internalement dans le compilateur, et qu'il est passé au linker.
Un tel choix ne peut se justifier que dans les cas où il est
imposé par une API bien définie pour le C++ sur la plateforme --
c'est le cas de l'architecture IA-64 d'Intel, je crois, mais
d'aucune autre plateforme à ma connaissance. (On pourrait aussi
poser la question sur le choix dans l'API. Mais ce n'est plus la
faute des auteurs du compilateur, qui sont bien obligé de
s'aligner.)
Encore que là, il faut voir ce qui se passe entre différentes
compilations.
Dans la pratique, ça m'étonne que tu rétrouves les mêmes noms
pour des classes définies dans l'espace référentiel anonyme. La
plupart des compilateurs (enfin, je crois -- la plupart dont je
me sers, en tout cas) génère un nouveau nom interne pour cet
espace à chaque compilation. Ce qui pose aussi parfois des
problèmes pour les compilateurs qui se servent des répositoires
pour les templates. Dans la pratique, j'ai du remplacer un
certain nombre d'espaces anonyme par des espaces nommés (du
genre « namespace <nomDuFichier>_Private ») ; jusqu'ici, je
pourrais dire que c'était pour contourner les défauts du
compilateur, mais si je voulais utiliser les typeid().name()
comme clé externe quelque part, il me le faudrait aussi, même
dans défaut de compilateur.
Seulement, évidemment, dans la mésure où les noms générés ne
sont pas garanti unique, et qu'ils varient d'un compilateur à
l'autre, je préfère encore utiliser mes propres noms, avec du
code que j'ai écris à la main. C'est plus de travail, mais au
moins, je sais que ça marchera partout.
--
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 me remets à C++ après quelques années de Python intensif, et c'est dur, je suis très rouillé...
Je serai curieux de savoir ce qui te fait passer de python à C++.
Les deux langages s'adressent à de différents domaines d'application, je crois. Python, c'est un langage de script ; il est hors question de s'en servir pour la majorité de mes applications. En revanche, pour les petits boulots d'appoint, il ne me vient pas à l'ésprit de me lancer dans toutes les complexités de la compilation et des fichiers make.
alors que normalement je m'attends d'après l'exemple à avoir des ProductA1 ou ProductA2 à la place des AbstractProductA.
Le plus bizarre c'est que le schéma Factory semble bien fonctionner avec les produits B et pas avec les produits A.
La différence de comportement s'explique par le fait que les produits B sont polymorphiques alors que les produits A ne le sont pas. (AbstractProductA ne comporte aucune méthode virtuelle alors que AbstractProductB en possède une.)
Tout à fait. La norme dit que typeid ne donne le type dynamique que si l'objet est polymorphe. Pour être polymorphe, il faut que l'objet soit de type classe, et que la classe comporte au moins une fonction virtuelle.
Sinon une autre question : pourquoi la fonction typeid(variable).name() > ne donne-t-elle pas un type de
classe ou de variable bien propre comme > dans la plupart des docs mais rajoute quelques chiffres ? Par exemple, > pourquoi obtiens-je "9ProductB1" à la place de "ProductB1" ?
Je ne sais pas ce que tu entends par "la plupart des docs" mais je pense que le comportement de typeid(...).name() n'est pas standard. Les implémentations doivent garantir l'unicité du nom à priori.
Même pas. Il y a eu une proposition de normaliser la chaîne renvoyée, mais elle n'a pas aboutie.
Note bien aussi qu'il y a une tension entre le désir de renvoyer un nom clair et compréhensible pour l'utilisateur, et le désir de renvoyer un nom unique -- pense à des classes dans l'espace référentiel anonyme, ou locales à une fonction, par exemple. En général, vue que dans l'absence d'une normalisation, à peu près la seule chose qu'on peut en faire, c'est de l'afficher, d'un point de vue « qualité d'implémentation », un nom en clair s'impose, d'autant plus qu'on peut le rendre unique à peu de prix dans la plupart des cas (et je crois qu'on accepterait des caractères en plus dans l'espace de nommage anonyme, ou pour des classes locales -- la proposition dont j'ai parlé précédait les espaces référentiels anonymes, mais elle traitait bien le cas des classes locales).
Malheureusement, certaines implémentations ont pris le chemin de la paresse, et sort le nom décoré, tel qu'il apparaît internalement dans le compilateur, et qu'il est passé au linker. Un tel choix ne peut se justifier que dans les cas où il est imposé par une API bien définie pour le C++ sur la plateforme -- c'est le cas de l'architecture IA-64 d'Intel, je crois, mais d'aucune autre plateforme à ma connaissance. (On pourrait aussi poser la question sur le choix dans l'API. Mais ce n'est plus la faute des auteurs du compilateur, qui sont bien obligé de s'aligner.)
Encore que là, il faut voir ce qui se passe entre différentes compilations.
Dans la pratique, ça m'étonne que tu rétrouves les mêmes noms pour des classes définies dans l'espace référentiel anonyme. La plupart des compilateurs (enfin, je crois -- la plupart dont je me sers, en tout cas) génère un nouveau nom interne pour cet espace à chaque compilation. Ce qui pose aussi parfois des problèmes pour les compilateurs qui se servent des répositoires pour les templates. Dans la pratique, j'ai du remplacer un certain nombre d'espaces anonyme par des espaces nommés (du genre « namespace <nomDuFichier>_Private ») ; jusqu'ici, je pourrais dire que c'était pour contourner les défauts du compilateur, mais si je voulais utiliser les typeid().name() comme clé externe quelque part, il me le faudrait aussi, même dans défaut de compilateur.
Seulement, évidemment, dans la mésure où les noms générés ne sont pas garanti unique, et qu'ils varient d'un compilateur à l'autre, je préfère encore utiliser mes propres noms, avec du code que j'ai écris à la main. C'est plus de travail, mais au moins, je sais que ça marchera partout.
-- 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
Damien Wyart
* "Ahmed MOHAMED ALI" in fr.comp.lang.c++:
Je serai curieux de savoir ce qui te fait passer de python à C++.
Juste un projet ponctuel ; je n'abandonne pas Python.
* in fr.comp.lang.c++:
Les deux langages s'adressent à de différents domaines d'application, je crois. Python, c'est un langage de script ; il est hors question de s'en servir pour la majorité de mes applications. En revanche, pour les petits boulots d'appoint, il ne me vient pas à l'ésprit de me lancer dans toutes les complexités de la compilation et des fichiers make.
Je pense que ça n'est pas du tout aussi tranché. Zope est un exemple d'application de grande ampleur écrite en Python. Voir par exemple le site www.pythonology.org pour plus de détails sur cette question.
Merci beaucoup à tous les deux pour vos explications très complètes.
-- DW
* "Ahmed MOHAMED ALI" <ahmedmo@wanadoo.fr> in fr.comp.lang.c++:
Je serai curieux de savoir ce qui te fait passer de python à C++.
Juste un projet ponctuel ; je n'abandonne pas Python.
* kanze@gabi-soft.fr in fr.comp.lang.c++:
Les deux langages s'adressent à de différents domaines d'application,
je crois. Python, c'est un langage de script ; il est hors question de
s'en servir pour la majorité de mes applications. En revanche, pour
les petits boulots d'appoint, il ne me vient pas à l'ésprit de me
lancer dans toutes les complexités de la compilation et des fichiers
make.
Je pense que ça n'est pas du tout aussi tranché. Zope est un exemple
d'application de grande ampleur écrite en Python. Voir par exemple le
site www.pythonology.org pour plus de détails sur cette question.
Merci beaucoup à tous les deux pour vos explications très complètes.
Je serai curieux de savoir ce qui te fait passer de python à C++.
Juste un projet ponctuel ; je n'abandonne pas Python.
* in fr.comp.lang.c++:
Les deux langages s'adressent à de différents domaines d'application, je crois. Python, c'est un langage de script ; il est hors question de s'en servir pour la majorité de mes applications. En revanche, pour les petits boulots d'appoint, il ne me vient pas à l'ésprit de me lancer dans toutes les complexités de la compilation et des fichiers make.
Je pense que ça n'est pas du tout aussi tranché. Zope est un exemple d'application de grande ampleur écrite en Python. Voir par exemple le site www.pythonology.org pour plus de détails sur cette question.
Merci beaucoup à tous les deux pour vos explications très complètes.