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 a écrit :
le code suivant ne semble pas compiler. Quelqu'un aurait-il une idée?
Merci pour votre aide.
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.
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 code suivant ne semble pas compiler. Quelqu'un aurait-il une idée? Merci pour votre aide.
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 code suivant ne semble pas compiler. Quelqu'un aurait-il une idée?
Merci pour votre aide.
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 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
Guillaume GOURDIN a écrit :
le code suivant ne semble pas compiler. Quelqu'un aurait-il une idée? Merci pour votre aide.
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é.
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é.
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é.
Ç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 !
Ç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 !
Ç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 !
//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
On Sep 25, 5:05 pm, Michael DOUBEZ <michael.dou...@free.fr> wrote:
Guillaume GOURDIN a écrit :
[...]
Ensuite, tu peux peut être avoir une sémantique à la auto_ptr<> mai s
c'est assez risqué.
//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:james.kanze@gmail.com
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
//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
James Kanze a écrit :
On Sep 25, 5:05 pm, Michael DOUBEZ wrote:
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 a écrit :
On Sep 25, 5:05 pm, Michael DOUBEZ <michael.dou...@free.fr> wrote:
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.
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
On Sep 26, 9:08 am, Michael DOUBEZ wrote:
James Kanze a écrit :
> On Sep 25, 5:05 pm, Michael DOUBEZ wrote: >> 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
On Sep 26, 9:08 am, Michael DOUBEZ <michael.dou...@free.fr> wrote:
James Kanze a écrit :
> On Sep 25, 5:05 pm, Michael DOUBEZ <michael.dou...@free.fr> wrote:
>> 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:james.kanze@gmail.com
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
> On Sep 25, 5:05 pm, Michael DOUBEZ wrote: >> 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
