List de ofstream

Le
Guillaume GOURDIN
Bonjour à tous,


le code suivant ne semble pas compiler. Quelqu'un aurait-il une idée?
Merci pour votre aide.

struct img_data
{
ofstream img;
ofstream img_param;
};

list<img_data> ofstreams_img;
img_data img;

img.img.open( "foo" );
img.img_param.open( "bar" );

ofstreams_img.push_back( img );
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sylvain Togni
Le #17336381
Guillaume GOURDIN a écrit :

le code suivant ne semble pas compiler. Quelqu'un aurait-il une idée?
Merci pour votre aide.

struct img_data
{
ofstream img;
ofstream img_param;
};

list<img_data> ofstreams_img;
img_data img;

img.img.open( "foo" );
img.img_param.open( "bar" );

ofstreams_img.push_back( img );



Le message d'erreur devrait te mettre sur la piste (mais bon
comme souvent avec les template, celui-ci ne doit pas être
très clair). Le compilateur a du t'indiquer qu'il ne peut pas
accéder au constructeur par copie de img_data, ou quelque chose
comme ça, ce qui est normal car les streams n'en ont pas (quel
en serait la sémantique, d'ailleurs ?) et donc la classe img_data
non plus. Hors un des pré-requis pour utiliser un container
standard est la présence d'un tel constructeur.

--
Sylvain Togni
Guillaume GOURDIN
Le #17336541
>> le code suivant ne semble pas compiler. Quelqu'un aurait-il une idée?
Merci pour votre aide.

struct img_data
{
ofstream img;
ofstream img_param;
};

list<img_data> ofstreams_img;
img_data img;

img.img.open( "foo" );
img.img_param.open( "bar" );

ofstreams_img.push_back( img );



Le message d'erreur devrait te mettre sur la piste (mais bon
comme souvent avec les template, celui-ci ne doit pas être
très clair). Le compilateur a du t'indiquer qu'il ne peut pas
accéder au constructeur par copie de img_data, ou quelque chose
comme ça, ce qui est normal car les streams n'en ont pas (quel
en serait la sémantique, d'ailleurs ?) et donc la classe img_data
non plus. Hors un des pré-requis pour utiliser un container
standard est la présence d'un tel constructeur.



Effectivement, c'est que j'avais cru deviner. Y a t'il donc un moyen
usuel de stocker des streams dans un container?
Michael DOUBEZ
Le #17336701
Guillaume GOURDIN a écrit :
le code suivant ne semble pas compiler. Quelqu'un aurait-il une idée?
Merci pour votre aide.

struct img_data
{
ofstream img;
ofstream img_param;
};

list<img_data> ofstreams_img;
img_data img;

img.img.open( "foo" );
img.img_param.open( "bar" );

ofstreams_img.push_back( img );



Le message d'erreur devrait te mettre sur la piste (mais bon
comme souvent avec les template, celui-ci ne doit pas être
très clair). Le compilateur a du t'indiquer qu'il ne peut pas
accéder au constructeur par copie de img_data, ou quelque chose
comme ça, ce qui est normal car les streams n'en ont pas (quel
en serait la sémantique, d'ailleurs ?) et donc la classe img_data
non plus. Hors un des pré-requis pour utiliser un container
standard est la présence d'un tel constructeur.



Effectivement, c'est que j'avais cru deviner. Y a t'il donc un moyen
usuel de stocker des streams dans un container?



Le problème est que ça ne fait pas sens de copier une stream. La
solution la plus propre serait de stocker des pointeurs.

Ensuite, tu peux peut être avoir une sémantique à la auto_ptr<> mais
c'est assez risqué.

struct img_data
{
ofstream img;
ofstream img_param;

img_data(){}
img_data(img_data&d)
{
swap(d);
}

img_data& operator=(img_data&d)
{
swap(d);
}

//attention, swaping efface l'état des streams comme clear()
void swap(img_data&d)
{
d.img.rdbuf(img.rdbuf(d.img.rdbuf()));
d.img_param.rdbuf(img_param.rdbuf(d.img_param.rdbuf()));
}
};

--
Michael
pjb
Le #17339841
Guillaume GOURDIN
Bonjour à tous,


le code suivant ne semble pas compiler. Quelqu'un aurait-il une idée?
Merci pour votre aide.

struct img_data
{
ofstream img;
ofstream img_param;
};

list<img_data> ofstreams_img;
img_data img;

img.img.open( "foo" );
img.img_param.open( "bar" );
ofstreams_img.push_back( img );



Ça me parait tout à fait normal. Toutes les instructions doivent
faire parti d'une function ou d'une méthode. On ne peut pas laisser
trainer des instructions comme ça au millieu d'un fichier en C ou C++.
En plus, il faudrait définir les types ofstream, et list avant
d'envisager une compilation. Tu as oublié quelques #include !


--
__Pascal Bourguignon__ http://www.informatimago.com/

This universe shipped by weight, not volume. Some expansion may have
occurred during shipment.
James Kanze
Le #17340291
On Sep 25, 5:05 pm, Michael DOUBEZ
Guillaume GOURDIN a écrit :



[...]
Ensuite, tu peux peut être avoir une sémantique à la auto_ptr<> mai s
c'est assez risqué.



struct img_data
{
ofstream img;
ofstream img_param;



img_data(){}
img_data(img_data&d)
{
swap(d);
}



img_data& operator=(img_data&d)
{
swap(d);
}



//attention, swaping efface l'état des streams comme clear()
void swap(img_data&d)
{
d.img.rdbuf(img.rdbuf(d.img.rdbuf()));
d.img_param.rdbuf(img_param.rdbuf(d.img_param.rdbuf()));
}
};



Ça, on peut le dire (que c'est risqué). Encore qu'avec list<>,
peut-être.

On pourrait aussi en faire un wrapper, à peu près comment j'ai
fait dans mon OutputStreamWrapper. Mais ça suppose des
allocations dynamique aussi, dans img_data. Alors, autant
utiliser boost::shared_ptr.

--
James Kanze (GABI Software) email:
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
Michael DOUBEZ
Le #17342561
James Kanze a écrit :
On Sep 25, 5:05 pm, Michael DOUBEZ
Guillaume GOURDIN a écrit :



[...]
Ensuite, tu peux peut être avoir une sémantique à la auto_ptr<> mais
c'est assez risqué.[snip]



Ça, on peut le dire (que c'est risqué). Encore qu'avec list<>,
peut-être.



Avec C++Ox, il sera possible de réimplémenter des container pour les
types qui ont une sémantique de move mais pas de copie; les contraintes
seraient alors au niveau du container: pas copiable mais moveable. Ca
résoudrait ce genre de cas.
Je ne sais pas si c'est prévu pour l'instant.

On pourrait aussi en faire un wrapper, à peu près comment j'ai
fait dans mon OutputStreamWrapper. Mais ça suppose des
allocations dynamique aussi, dans img_data. Alors, autant
utiliser boost::shared_ptr.



Boost a aussi des wrappers pour des containers de pointeurs, j'ai essayé
de les utiliser l'année dernière mais sans grand succès; et j'étais pas
très motivé pour chercher plus longtemps.

--
Michael
James Kanze
Le #17343221
On Sep 26, 9:08 am, Michael DOUBEZ
James Kanze a écrit :



> On Sep 25, 5:05 pm, Michael DOUBEZ >> Guillaume GOURDIN a écrit :



> [...]
>> Ensuite, tu peux peut être avoir une sémantique à la
>> auto_ptr<> mais c'est assez risqué.[snip]



> Ça, on peut le dire (que c'est risqué). Encore qu'avec list<>,
> peut-être.



Avec C++Ox, il sera possible de réimplémenter des container
pour les types qui ont une sémantique de move mais pas de
copie; les contraintes seraient alors au niveau du container:
pas copiable mais moveable. Ca résoudrait ce genre de cas.
Je ne sais pas si c'est prévu pour l'instant.



Les containeur doivent supporter les movable, et les istream et
les ostream doivent être movable.

--
James Kanze (GABI Software) email:
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
Publicité
Poster une réponse
Anonyme