Discussion :

[r0d]

Bonjour à tous,

je me retrouve avec un problème à résoudre, et j'ai bien peur que la solution la plus élégante pour le faire soit l'utilisation d'une ellipse.
Cependant, j'ai du mal avec cette étrange chose. Voici ma fonction:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#include <string>
#include <iostream>
 
using namespace std;
 
// cette fonction est censé prendre une nombre quelconque de string en paramètre et les afficher
void Write(std::string args, ...)
{
	string str;
	va_list vl;
 
	str=args;
 
	va_start(vl,args);
 
	do {
		cout << str;
		str=va_arg(vl, string);
	} while (!str.empty());
 
	va_end(vl);
	cout << endl;
}

Lorsque je tente d'utiliser ma fonction ainsi:

Code :

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

1
2
3
4
5
6
int main(int argc, char* argv[])
{
	Write(string("toto"), string("titi"), string("tata"));
 
	return 0;
}

Le programme plante à la dernière itération de la boucle do/while dans la fonction Write(), à la ligne:

Code :

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

str=va_arg(vl, string);

Le débugger m'amène dans le fichier memcpy.asm à la ligne

rep movsd ;N - move all of our dwords

avec le message d'erreur suivant:

Unhandled exception at 0x10231f1a (msvcr80d.dll) in Test1.exe: 0xC0000005: Access violation reading location 0x0a5cf99c.

Avez-vous une idée de ce qui cloche?

[Ulmo]

Ta routine attend une chaine vide pour sortir de la boucle. Ton appel doit être :

Code :

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

Write(string("toto"), string("titi"), string("tata"), string());

[loufoque]

Tu ne peux pas utiliser les varags pour des non-PODs.

[r0d]

Tu ne peux pas utiliser les varags pour des non-PODs.

Bah pourtant ça fonctionne avec la solution proposée par Ulmo. Code compilé sous windows avec VS2005.

[r0d]

Ta routine attend une chaine vide pour sortir de la boucle. Ton appel doit être :

Code :

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

Write(string("toto"), string("titi"), string("tata"), string());

Merci
N'existet-il pas une feinte pour se passer de ce dernier élément?

[Laurent Gomila]

Pourquoi ne pas utiliser un flux (ou tout du moins une solution à base de chaînage d'appels) ?

Code :

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

MonFlux << "toto" << "titi" << "tata";

[r0d]

Pourquoi ne pas utiliser un flux (ou tout du moins une solution à base de chaînage d'appels) ?

Code :

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

MonFlux << "toto" << "titi" << "tata";

Car en fait, dans mon cas,
1) ce ne seront pas des string que j'aurais en paramètre, mais des classes que je vais devoir créer.
2) je ne vais pas faire un cout dessus, mais je vais devoir faire quelques traitements dessus.

Ensuite, j'ai d'autres difficultés, c'est que ma fonction Write devra prendre des arguments de type différents. Je pense donc que je vais devoir créer mes propres types qui héritent d'une interface IDummy et mon Write va se présenter ainsi: void Write(IDummy dum1 ...);

C'est absolument horrible, mais je ne vois pas comment je pourrais faire autrement.

[Matthieu Brucher]

Tu peux :
- passer un std::vector<Dummy*>& pour éviter cette horreur
- utiliser un visiteur pour tes traitements plutôt
- ...

[r0d]

- passer un std::vector<Dummy*>& pour éviter cette horreur

Oui en effet, tout simplement...
pas la grande forme moi ^^

[Luc Hermitte]

Ouaip. Parce que march'ra paas!

C'est pas vraiment déterministe le non-POD dans les fonctions à ellipse. Avec un même compilo, pour une même plateforme cible, la même fonction, parfois le résultat espéré est obtenu, parfois ça crashe de toute beauté.

De toutes façons, avec ton héritage, tu aurais dû obligatoirement passer des pointeurs sur ton interface (ben ouais, la sémantique de copie n'est pas vraiment compatible avec des hiérarchies polymorphes), et du coup tu aurais pû t'en sortir.
Mais franchement!

[Médinoc]

Pourquoi ne pas faire une classe qui s'emploierait comme un flux ?
Je ne vois rien qui l'en empêche (c'est indépendant de tes contraintes 1 et 2), sauf si "3: le traitement d'une string dépend des strings qui la suivent (ou de leur absence)".

Si tu n'as pas cette contrainte, alors rien ne t'empêche de faire "Write("toto"); Write("tata"); Write("titi");"
que tu peux, si tu le souhaites, transformer en "MonObjetPerso << "toto" << "tata" < "titi";"Je ne peux pas faire comme ça, car en effet, mon traitement dépend du nmobre d'objets passés en paramètre. En fait, j'effectue une sorte de sérialization (ou formattage) avec les données contenues dans les classes que je reçois en paramètre.

Au final, j'ai fais un truc assez moche, mais qui est plus simple à utiliser. J'ai appris, assez tard hier soir, que je n'aurais jamais plus de 4 paramètres dans cette fonction en fait. J'ai donc surchargé ma fonction 4 fois:

Code :

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

1
2
3
4
Write(MonInterface* i);
Write(MonInterface* i1, MonInterface* i2);
Write(MonInterface* i1, MonInterface* i2, MonInterface* i3);
Write(MonInterface* i1, MonInterface* i2, MonInterface* i3, MonInterface* i4);

C'est assez moche (notamment en terme de maintenabilité), mais finalement, ça simplifie l'utilisation, ce qui était la contrainte la plus importante.

[Médinoc]

Ouaip. Parce que march'ra paas!

C'est pas vraiment déterministe le non-POD dans les fonctions à ellipse. Avec un même compilo, pour une même plateforme cible, la même fonction, parfois le résultat espéré est obtenu, parfois ça crashe de toute beauté.

Exact.
Sous Visual par exemple, le contenu du type est directement empilé comme si c'était une structure POD. C'est pourquoi les CString de MFC contiennent juste un pointeur sur les caractères, pour passer pour une simple chaîne dans un printf() ou un CString::Format().

[loufoque]

Les varargs avec des non-PODs c'est du comportement indéfini.
Après, de manière réaliste, on se doute bien que ça marche quand même, sauf que la copie se fait bit à bit au lieu d'utiliser le constructeur par recopie.
Ce qui est pas plus mal dans ton cas en fait puisque tu ne modifies pas la chaîne.