Discussion :

[méphistopheles]

Si tu ne veux pas essayer / tester / comprendre, on ne peut rien faire pour toi.

j'ai testé! que veux tu que je modifie par rapport à mon premier test pour tester tes optimisations compilateurs ?

En l'occurence, ton constructeur attend ici un const std::string&, et le compilateur va essayer de trouver une conversion entre un const char[] et un const std::string& (ça tombe bien y'en a un).

Dans quel exemple ?
Dans celui que je viens de donner, je fournis un std::string et le compilo les passe en std string au lieu d'un const std::string &... Dans l'autre ça ne compile pas je ne vois pas de quoi tu parle. Dans le cas ou tu veux me faire faire une modification sur mon code auparavant (pour tester les optimisations compilateur), pourrais-tu être plus clair sur ce qu'il faut tester/modifier/essayer/comprendre ? Je dois être idiot, mais je n'arrive pas à savoir de quoi tu parle.

Et c'est définitivement une mauvaise raison

Une fois de plus, de quoi parle tu ? quand je lis ton post, j'ai l'impression d'avoir perdu la moitié de mon cerveau cette nuit et de ne pas être capable de suivre un propos

[zul]

Le code que j'ai indiqué dans le post #12 ? (qui utilise un le call_traits correctement, mais sur Wrapped).

Et je ne vois pas le rapport avec les optimisations compilos (à par qu'avec le RVO, passer une std::string ou une const std::string& dans ce contexte précis, ça doit pas changer grand chose).

Les mauvaises raisons sont par rapport à l'utilisation de pointeur sur std::string dans ce contexte (et je ne parle pas de pointer sur un objet existant, mais d'allouer une string sur le tas avec un new, d'utiliser des pointeurs nus et de gérer (probablement mal) leur durée de vie de cette façon)). Après tu en fais bien ce que tu veux, je suis juste curieux de savoir pourquoi tu veux faire ce genre de "choses" ?

[méphistopheles]

Le code que j'ai indiqué dans le post #12 ? (qui utilise un le call_traits correctement, mais sur Wrapped).

désolé je l'avait complétement oblitéré, je me rappelais qu'il était pareil en fait donc déjà compilé. toutes mes excuses. ça marche bien
Le reste de mes propos incohérent vient de cette mésentente (merci de m'avoir remis le cerveau en place. faut juste que je change de mémoire)

Les mauvaises raisons sont par rapport à l'utilisation de pointeur sur std::string dans ce contexte (et je ne parle pas de pointer sur un objet existant, mais d'allouer une string sur le tas avec un new, d'utiliser des pointeurs nus et de gérer (probablement mal) leur durée de vie de cette façon)). Après tu en fais bien ce que tu veux, je suis juste curieux de savoir pourquoi tu veux faire ce genre de "choses" ?

en fait, je compte pointer sur un string existant car j'ai en gros un tableau qui est lié à un autre (plus petit) genre attribut, l'idée étant de serializer les deux. (boost serialization tenant compte de l'unicité des pointeurs).j'aurais également pu utiliser des identifiant mais la seconde base à tendance à se réordonner(mais c'est une liste) donc j'ai préféré des pointeurs... peut être es-ce un mauvais choix et qu'une lut aurait eu de meilleurs résultats...

en tout cas, merci beaucoup, le problème est résolu

[zul]

Pas de problème.

[Flob90]

pas vraiment un problème dans mon cas puique je n'ai pas d'autre objets à détruire...

A part que ne détruire que la base c'est le comportement de ton compilateur (et de la plus part il me semble), il ne reste que le comportement est indéfnie. Pour un wrapper j'aurai plus vue une compostion qu'un héritage.

[méphistopheles]

A part que ne détruire que la base c'est le comportement de ton compilateur (et de la plus part il me semble), il ne reste que le comportement est indéfnie.

de toutes façon, il y a bien un des destructeurs qui sera appelé et donc celui de la base le sera forcément non ?

Pour un wrapper j'aurai plus vue une compostion qu'un héritage.

le problème est que j'aimerais que mon wrapper soit transparent car j'aimerais que les utilisateurs d'une autre classe (qui l'utilisera en fait pour stocker des pointeurs) puissent l'utiliser sans avoir à passer par un get() ou un opérateur quelquonque et je me vois mal réécrir un wrapper par classe reproduisant toutes les méthodes (à moins que tu connaisse un moyen de le faire ....)

[Goten]

Nan, ce qu'il te dis c'est que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class A {};
 
class B : public A {};
 
 
int main()
{
     A* a = new B();
     delete a; // Paf UB destructeur de A non virtuel et public
}

[méphistopheles]

Nan, ce qu'il te dis c'est que :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
class A {};
 
class B : public A {};
 
 
int main()
{
     A* a = new B();
     delete a; // Paf UB destructeur de A non virtuel et public
}

he bien ? c'est certes un UB, mais un destructeur sera focrément appelé non que ce soit celui de A ou celui de B. et dans mon cas cela importe peu...

[Goten]

Ah, bah alors si ça te gêne pas d'avoir des comportements indéfinis ... J'espère que tu conçois pas un système critique / ayant trait à la sécurité..

(ou alors t'as pas saisi la notion d'UB)

[méphistopheles]

Ah, bah alors si ça te gêne pas d'avoir des comportements indéfinis ... J'espère que tu conçois pas un système critique / ayant trait à la sécurité..

(ou alors t'as pas saisi la notion d'UB)

Non, il n'est pas critique, mais je n'ai peut-être pas bien saisi les tenants et les aboutissant des UB .... pourrait-tu développer s'il te plais ?

merci

[gl]

Non, il n'est pas critique, mais je n'ai peut-être pas bien saisi les tenants et les aboutissant des UB .... pourrait-tu développer s'il te plais ?

Pour faire simple, en cas de comportement indéfini (UB), l'implémentation est en droit de faire ce qu'elle souhaite (donc en toute rigueur, une implémentation qui reformate le disque dur ou qui envoie un mail d'insulte à tous tes contacts serait conforme), pas forcément toujours la même chose (en fonction des options d'optimisation par exemple) et n'a pas l'obligation de documenter le comportement.

[méphistopheles]

Je vois le cas de la destruction de pointeur sur classe de base avec destructeur public non virtuel n'étant pas abordé par la norme, le compilo choisit le comportement à adopter. J'ignorer l'existences d' UB comme cela.

Pour ma part, j'ai finalement abandonné cette idée de wrapper car cela ne me permettais pas de résoudre mon problème et j'ai imposé à l'utilisateur d'avoir des pointeurs serializable.


enfin bon, quand c'est pas possible, il faut parfois lâcher l'affaire.


merci à tous

[gl]

Je vois le cas de la destruction de pointeur sur classe de base avec destructeur public non virtuel n'étant pas abordé par la norme, le compilo choisit le comportement à adopter. J'ignorer l'existences d' UB comme cela.

En fait, ce n'est pas propre à l'absence de destructeur virtuel, c'est la définition même d'un UB (Undefined Behavior) : la norme n'impose rien, tout est permis.

[Flob90]

Sinon, même si tu en as plus besoin, ton code avec boost::call_traits ne peut pas compiler car il ne peut pas créer le constrcuteur associé. La détermination des types dans les templates est automatique c'est vraie, mais faut quand même quelle soit possible, dans ton cas il peut y avoir une infinité de type T qui donnerait un constrcuteur valide, comment le compilateur choisie lequel prendre ? Il ne peut pas, il ne le fait pas (ou alors c'est un UB, à vérifier).