[Syntaxe] temporaire non nommé et constructeur copie privée

Version imprimable

Voir 40 message(s) de cette discussion en une page

24/05/2007, 10h31
lun4t1k

:aie:
24/05/2007, 11h01
Jean-Marc.Bourguet

Citation:

Envoyé par Charlemagne

Pour créer un nouvel objet, il faut appeler un constructeur tout court, pas son constructeur de copie.

Pour creer un objet a partir d'une rvalue, il faut le copier, donc utiliser le constructeur de copie)

(Note que la prochaine version de la norme aura des rvalue references qui n'auront pas cette exigence).

Citation:

Je trouve pas que ce soit si courant que ça. En tout cas l'immense majorité des objets devrait être copiable.

Pourquoi. La semantique de valeur -- ou la copie a du sens -- et une semantique de reference -- ou les virtuelles ont du sens -- vont generalement mal ensemble.

Citation:

Dans la STL c'est le cas. (Toutefois par ex les streams ne sont pas copiables).

La STL fournit essentiellement des classes ayant une semantique de valeur et sans virtuelles.
24/05/2007, 11h11
David Fleury

Citation:

Envoyé par Jean-Marc.Bourguet

Pour creer un objet a partir d'une rvalue, il faut le copier, donc utiliser le constructeur de copie)

(Note que la prochaine version de la norme aura des rvalue references qui n'auront pas cette exigence).

Visual serait-il alors en avance ? ( vision optimiste du bug )

Citation:

Envoyé par Jean-Marc.Bourguet

Pourquoi. La semantique de valeur -- ou la copie a du sens -- et une semantique de reference -- ou les virtuelles ont du sens -- vont generalement mal ensemble.

Dans mon cas, je crois que ce serait plutôt lié à une ressource externe partagée, et qu'il faudrait sûrement introduire une notion de pointeur intelligent par exemple. ( enfin c'est l'idée que j'en ai, je ne suis pas un théoricien).

Mon objet à l'origine n'est pas copiable à cause d'un de ses membres qui ne l'est pas (un std::ostringstream justement).
24/05/2007, 11h47
Charlemagne

Bref, si le constructeur de copie est visiblement exigé par le standard,ça serait pour une salade interne aux compilos, mais de toute évidence pas indispensable à tous les compilos.

Citation:

Envoyé par Jean-Marc.Bourguet

La STL fournit essentiellement des classes ayant une semantique de valeur et sans virtuelles.

(j'utilise rarement les fonctions virtuelles, dans mes calculs le polymorphisme statique par template est bien plus rapide)
Encore une fois: quel est le rapport entre le constructeur de copie et les fonctions virtuelles?

Pourquoi donc est-ce "rare d'avoir des classes copiables qui ont des fonctions virtuelles" ? certes un "constructeur de copie virtuel" (clone) est parfois nécessaire, mais ça n'empêche pas l'existence de constructeur de copie normal.

Et je ne pense pas que les streams ne sont pas copiables à cause des fonctions virtuelles qu'ils contiendraient mais plutôt à cause d'une sécurité pour éviter l'accès multiple à une ressource.

PS

Citation:

Envoyé par Hylvenir

Dans mon cas, je crois que ce serait plutôt lié à une ressource externe partagée, et qu'il faudrait sûrement introduire une notion de pointeur intelligent par exemple. ( enfin c'est l'idée que j'en ai, je ne suis pas un théoricien).

Mon objet à l'origine n'est pas copiable à cause d'un de ses membres qui ne l'est pas (un std::ostringstream justement).

Je crois pas que ce soit une bonne idée, puisque tu contournerais justement la sécurité. Mais ça dépend peut-être du contexte...
Peut-être que tu peux sortir ta variable membre ostringstream de la classe...
24/05/2007, 12h50
David Fleury

Citation:

Envoyé par Charlemagne

Peut-être que tu peux sortir ta variable membre ostringstream de la classe...

C'était en effet l'idée pour éviter ce problème.
Mais pour le moment, pas le temps. je fais avec.
24/05/2007, 20h20
Jean-Marc.Bourguet

Citation:

Envoyé par Hylvenir

Visual serait-il alors en avance ? ( vision optimiste du bug)

Non, il y a une nouvelle syntaxe.
24/05/2007, 20h51
Jean-Marc.Bourguet

Citation:

Envoyé par Charlemagne

Bref, si le constructeur de copie est visiblement exigé par le standard,ça serait pour une salade interne aux compilos, mais de toute évidence pas indispensable à tous les compilos.

Ce n'est pas une salade interne aux compilos, c'est une salade interne à la norme. Le langage est défini d'une certaine façon et certaines conséquences des règles sont parfois plus ou moins suprenantes. On peut après essayer d'introduire des exceptions, mais elles cassent la cohérence interne et ont tendance à produire en fait des résultats encore plus surprenant.

Citation:

(j'utilise rarement les fonctions virtuelles, dans mes calculs le polymorphisme statique par template est bien plus rapide)

Deux outils différents ayant des caractéristiques différentes. Il est des choses que l'un fait bien et que l'autre ne sait pas faire (vérifier statiquement les types, effectuer des choix dynamiques), et c'est généralement ces caractéristiques là plus que les perfs qui sont des critères déterminants.

Citation:

Encore une fois: quel est le rapport entre le constructeur de copie et les fonctions virtuelles?

Pourquoi donc est-ce "rare d'avoir des classes copiables qui ont des fonctions virtuelles" ? certes un "constructeur de copie virtuel" (clone) est parfois nécessaire, mais ça n'empêche pas l'existence de constructeur de copie normal.

Rien n'empeche dans le langage. Il y a même des cas où c'est utile. Mais en pratique ces cas sont rares. Ce lieu se prète mal à faire un cours de conception -- et je n'ai pas ni le temps ni réellement l'envie. Rapidement, on peut considérer qu'il y a deux types de classes: celles qui représentent des valeurs essentiellement immuables (même si pour la facilité on fournit parfois des membres qui modifient l'objet mais leur sémantique est essentiellement l'assignation d'une nouvelle valeur dérivée de l'ancienne), pour lesquelles la copie et l'égalité ont un sens et n'importe quel copie d'une valeur se comporte de la même manière; et celles qui représentent des entités mutables, pour lesquelles il n'y a pas réellement de notion d'égalité mais plutôt d'identité, où la copie n'a généralement pas de sens et quand elle en a il s'agit plutôt de création d'un nouvel objet ayant des attributs identiques à ceux de l'objet copiés mais sans qu'on considère qu'ils sont égaux -- il s'agit de ta fonction clone.

Les fonctions virtuelles n'ont pas d'utilité dans le premier cas, parce que comme on manipule des objets par valeur, le type est fixé statiquement et donc il n'y a pas de dispatch. L'héritage même est pour ces types souvent un héritage d'implémentation qui serait théoriquement mieux privé.

Dans le second cas, on manipule des pointeurs et la copie est impossible car on ne connait souvent pas le type exact -- clone est possible parce qu'il retourne un pointeur.

Citation:

Et je ne pense pas que les streams ne sont pas copiables à cause des fonctions virtuelles qu'ils contiendraient mais plutôt à cause d'une sécurité pour éviter l'accès multiple à une ressource.

Les streams ne sont pas copiables parce qu'elles sont des entités ayant un état et non des variables ayant une valeur.
24/05/2007, 20h54
Jean-Marc.Bourguet

Citation:

Envoyé par Hylvenir

Mon objet à l'origine n'est pas copiable à cause d'un de ses membres qui ne l'est pas (un std::ostringstream justement).

Pour proposer une solution, il me faudrait comprendre le problème. Apparemment, il s'agit d'un problème de conception plus que d'un problème de C++ (j'ai du mal à voir pourquoi tu utilises une relation aussi forte avec quelque chose qui est une ressource externe).

Citation:

Envoyé par Jean-Marc.Bourguet

Pour proposer une solution, il me faudrait comprendre le problème. Apparemment, il s'agit d'un problème de conception plus que d'un problème de C++ (j'ai du mal à voir pourquoi tu utilises une relation aussi forte avec quelque chose qui est une ressource externe).

Allons-y gaiement...
Ma classe permet de formatter des messages
Code:

1 2 3 4 5 6 7 struct Format { ostringstream buffer; Format( const char* msg ) { buffer << msg; } template<..>Format( const char* msg, const T& t ) { buffer << msg << t; } std::string str() { return buffer.str(); } };
Le but étant de l'utiliser via des macros et une classe Log qui permet d'envoyer des messages formattés;
Code:

1 2 3 4 5 6 7 #define DEBUG( MSG ) { Logger l; l.send( (MSG) ) ); } int main() { int a = 3; DEBUG( LogFormat( "Mon message", 3 ) ); }
peut être qu'un simple pointeur sur le stream pourrait faire une sorte de décoration...

Ici mon problème est que je dois donc faire :
Code:

1 2 3 4 5 6 int main() { int a = 3; LogFormat lf("Mon message", 3 ); DEBUG( lf ); }
en simplifiant en peu le tout.

24/05/2007, 23h21
David Fleury

Citation:

Envoyé par Jean-Marc.Bourguet

Les streams ne sont pas copiables parce qu'elles sont des entités ayant un état et non des variables ayant une valeur.

j'aurais dit qu'"une entité ayant un état" (qui peux changer) est synonyme de "variable" :?

:aie:
24/05/2007, 23h28
Charlemagne
Citation:

Envoyé par Hylvenir

Ma classe permet de formatter des messages

Ma proposition pour éviter d'avoir une stream en variable membre:
-définir toi même ta classe stream de formatage
-surchargé l'opérateur <<
En fait de prendre modèle sur toutes les variations de streams de la STL.

ex:
Code:

1 2 3 4 5 6 7 8 9 class formated_stream { ... }; template<class T> formated_stream &operator<<(formated_stream &is, const T &x) { return is<<x; };
24/05/2007, 23h31
David Fleury

Citation:

Envoyé par Charlemagne

-définir toi même ta classe stream de formatage

j'aurais aimé éviter ça.
25/05/2007, 00h03
David Fleury

http://www.open-std.org/jtc1/sc22/op...6/special.html

J'ai trouvé sur les temporaires.
Avec sûrement une explication sur la nécessité du copy constructor.

Citation:

Envoyé par Hylvenir

j'aurais aimé éviter ça.

C'est pourtant pas compliqué: si tu dérives ta classe de basic_ostringstream il ne suffit plus les opérateurs << qui doivent agir différemment d'un ostringstream

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
template <class E,class T=char_traits<E>,class A=allocator<E> >
my_basic_ostringstream : public basic_ostringstream<E,T,A>
{
  public:
    template<class X> explicit my_basic_ostringstream(const &X) : basic_ostringstream<E,T,A>(X) {}
};
 
typedef my_basic_ostringstream<char> my_ostringstream;
 
template<class E,class T,class A,class X> my_basic_ostringstream<E,T,A> &operator<<(my_basic_ostringstream<E,T,A>  &os, const X &x)
{
  basic_ostringstream<E,T,A> &oss=static_cast<basic_ostringstream<E,T,A> &>(os);
  oss<<x<<"blabla";
  return os;
}

25/05/2007, 08h37
David Fleury

Citation:

Envoyé par Charlemagne

C'est pourtant pas compliqué

Ce n'est pas une question de complexité mais plutôt de temps.

Mais je vais regarder ta solution.
Merci.
25/05/2007, 09h08
David Fleury

D'autant plus que si ma mémoire est bonne, c'es io_base qui n'est pas copiable. donc ça ne change pas mon problème.
A vérifier toutefois.
25/05/2007, 09h25
Jean-Marc.Bourguet

Citation:

Envoyé par Hylvenir

en simplifiant en peu le tout.

Peut-etre un peu trop. Le ostringstream n'a aucune raison d'etre membre, il n'est utilise que dans les constructeurs. Une variable locale a ceux-ci serait mieux.
25/05/2007, 09h39
Jean-Marc.Bourguet

Citation:

Envoyé par Hylvenir

j'aurais dit qu'"une entité ayant un état" (qui peux changer) est synonyme de "variable"

Il est vrai que l'etat de l'entite peut parfois etre considere comme une valeur (et utiliser ce fait est meme un pattern du bouquin du GOF), mais je crains que j'essayais d'expliquer n'est pas passe, et j'ai pas le temps de reprendre ca ab initio. Effectue une recherche sur entite et valeur (peut-etre meme dans ce forum, le sujet a deja ete traite et ca ne m'etonnerais pas que Luc ou Loic ait poste des liens ou meme des explications pertinentes).
25/05/2007, 09h42
David Fleury

Citation:

Envoyé par Jean-Marc.Bourguet

Il est vrai que l'etat de l'entite peut parfois etre considere comme une valeur (et utiliser ce fait est meme un pattern du bouquin du GOF), mais je crains que j'essayais d'expliquer n'est pas passe, et j'ai pas le temps de reprendre ca ab initio. Effectue une recherche sur entite et valeur (peut-etre meme dans ce forum, le sujet a deja ete traite et ca ne m'etonnerais pas que Luc ou Loic ait poste des liens ou meme des explications pertinentes).

Ok. Je comprends.
Je vais chercher.
Merci.
25/05/2007, 09h46
David Fleury

Citation:

Envoyé par Jean-Marc.Bourguet

Peut-etre un peu trop. Le ostringstream n'a aucune raison d'etre membre, il n'est utilise que dans les constructeurs. Une variable locale a ceux-ci serait mieux.

et stocker le résultat dans une std::string qui elle est copiable ?

La contrainte forte étant les performances.
mettre le stream en membre évitait de le construire plusieurs fois
mais en effet, il n'y a pas de raison.

Mais je vais essayer ce que tu proposes et mesurer ça.
Merci.

Voir 40 message(s) de cette discussion en une page