Une qestion que je me pose à propos de std::queue, suite à une
discussion sur developpez.com : Peut-on assigner un queue à une autre ?
Rien ne semble dire qu'on puisse le faire dans le standard (à moins que
par son placement dans le chapitre container, une std::queue soit
implicitement un container, en plus d'un container adaptator).
Rien ne semble dire qu'on ne puisse pas le faire, et en C++, ce genre
d'opération est défini automatiquement si rien ne les empêche, mais en
standardese, qu'en est-il ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Michael DOUBEZ
Bonjour,
Une qestion que je me pose à propos de std::queue, suite à une discussion sur developpez.com : Peut-on assigner un queue à une autre ?
Rien ne semble dire qu'on puisse le faire dans le standard (à moins que par son placement dans le chapitre container, une std::queue soit implicitement un container, en plus d'un container adaptator).
Rien ne semble dire qu'on ne puisse pas le faire, et en C++, ce genre d'opération est défini automatiquement si rien ne les empêche, mais en standardese, qu'en est-il ?
Merci,
Bonjour,
A partir du moment où c'est un container et à moins que cela ne soit spécifié autrement, le container a une fonction d'assignement (in linear time). C'est également le cas pour le constructeur par défaut et par copie, swap et clear,les fonctions d'iterator (begin,end,rbegin,rend) et les fonction de taille (size,max_size,empty).
Bonne journée
Bonjour,
Une qestion que je me pose à propos de std::queue, suite à une
discussion sur developpez.com : Peut-on assigner un queue à une autre ?
Rien ne semble dire qu'on puisse le faire dans le standard (à moins que
par son placement dans le chapitre container, une std::queue soit
implicitement un container, en plus d'un container adaptator).
Rien ne semble dire qu'on ne puisse pas le faire, et en C++, ce genre
d'opération est défini automatiquement si rien ne les empêche, mais en
standardese, qu'en est-il ?
Merci,
Bonjour,
A partir du moment où c'est un container et à moins que cela ne soit
spécifié autrement, le container a une fonction d'assignement (in linear
time).
C'est également le cas pour le constructeur par défaut et par copie,
swap et clear,les fonctions d'iterator (begin,end,rbegin,rend) et les
fonction de taille (size,max_size,empty).
Une qestion que je me pose à propos de std::queue, suite à une discussion sur developpez.com : Peut-on assigner un queue à une autre ?
Rien ne semble dire qu'on puisse le faire dans le standard (à moins que par son placement dans le chapitre container, une std::queue soit implicitement un container, en plus d'un container adaptator).
Rien ne semble dire qu'on ne puisse pas le faire, et en C++, ce genre d'opération est défini automatiquement si rien ne les empêche, mais en standardese, qu'en est-il ?
Merci,
Bonjour,
A partir du moment où c'est un container et à moins que cela ne soit spécifié autrement, le container a une fonction d'assignement (in linear time). C'est également le cas pour le constructeur par défaut et par copie, swap et clear,les fonctions d'iterator (begin,end,rbegin,rend) et les fonction de taille (size,max_size,empty).
Bonne journée
Loïc Joly
A partir du moment où c'est un container et à moins que cela ne soit spécifié autrement, le container a une fonction d'assignement (in linear time).
Le problème est que je n'ai vu nulle part que queue est un container...
L'introduction de queue mentionne : It also provides container adaptors that make it easy to construct abstract data types, such as stacks or queues, out of the basic sequence kinds
J'ai l'impression que si on avoit voulu dire que queue est un container, on aurait pu trouver une formulation moins lourde, et où le mot container apparaît (par exemple remplacer "abstract data types" par "container"), alors que là, on dirait qu'il est soigneusement évité.
-- Loïc
A partir du moment où c'est un container et à moins que cela ne soit
spécifié autrement, le container a une fonction d'assignement (in linear
time).
Le problème est que je n'ai vu nulle part que queue est un container...
L'introduction de queue mentionne :
It also provides container adaptors that make it easy to construct
abstract data types, such as stacks or queues, out of the basic sequence
kinds
J'ai l'impression que si on avoit voulu dire que queue est un container,
on aurait pu trouver une formulation moins lourde, et où le mot
container apparaît (par exemple remplacer "abstract data types" par
"container"), alors que là, on dirait qu'il est soigneusement évité.
A partir du moment où c'est un container et à moins que cela ne soit spécifié autrement, le container a une fonction d'assignement (in linear time).
Le problème est que je n'ai vu nulle part que queue est un container...
L'introduction de queue mentionne : It also provides container adaptors that make it easy to construct abstract data types, such as stacks or queues, out of the basic sequence kinds
J'ai l'impression que si on avoit voulu dire que queue est un container, on aurait pu trouver une formulation moins lourde, et où le mot container apparaît (par exemple remplacer "abstract data types" par "container"), alors que là, on dirait qu'il est soigneusement évité.
-- Loïc
James Kanze
Loïc Joly wrote:
A partir du moment où c'est un container et à moins que cela ne soit spécifié autrement, le container a une fonction d'assignement (in l inear time).
Le problème est que je n'ai vu nulle part que queue est un container...
En effet, je ne crois pas qu'elle en est une. C'est un adaptateur de collection, et je ne vois rien qui dit qu'un adaptateur de collection soit lui aussi une collection. Au contraire, pour être une collection, il faut impérativement qu'elle définisse des types d'itérateur. (Voir table 80 dans §23.1.)
L'introduction de queue mentionne : It also provides container adaptors that make it easy to construct abstract data types, such as stacks or queues, out of the basic sequence kinds
J'ai l'impression que si on avoit voulu dire que queue est un container, on aurait pu trouver une formulation moins lourde, et où le mot container apparaît (par exemple remplacer "abstract data types" par "container"), alors que là, on dirait qu'il est soigneusement évité.
Si on avait voulu dire que queue est une collection, on aurait bien défini tout ce qu'il faut pour qu'elle le soit. Une des caractèristiques de base des collections dans la STL, c'est on puisse en accéder à tous les éléments au moyen d'un itérateur, ce qui n'est pas le cas de queue.
En ce qui concerne la copie et l'affectation : c'est très indirect, mais la classe présentée dans la norme les a. Fourni par le compilateur, peut-être, mais elles y sont quand même. Quand on veut interdire la copie, on le dit (comme dans std::ios_base).
En revanche, évidemment, on n'hésite pas à les spécifier explicitement dans d'autres cas, comme complex. Alors, on pourrait arguer que c'est indéfini. Dans la mesure où on supporte (explicitement) les opérateurs de comparaison, je doute fort que l'intention était de ne pas permettre la copie, mais je crois qu'effectivement, la norme n'est pas claire ici.
-- 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
Loïc Joly wrote:
A partir du moment où c'est un container et à moins que cela ne soit
spécifié autrement, le container a une fonction d'assignement (in l inear
time).
Le problème est que je n'ai vu nulle part que queue est un container...
En effet, je ne crois pas qu'elle en est une. C'est un
adaptateur de collection, et je ne vois rien qui dit qu'un
adaptateur de collection soit lui aussi une collection. Au
contraire, pour être une collection, il faut impérativement
qu'elle définisse des types d'itérateur. (Voir table 80 dans
§23.1.)
L'introduction de queue mentionne :
It also provides container adaptors that make it easy to construct
abstract data types, such as stacks or queues, out of the basic sequence
kinds
J'ai l'impression que si on avoit voulu dire que queue est un container,
on aurait pu trouver une formulation moins lourde, et où le mot
container apparaît (par exemple remplacer "abstract data types" par
"container"), alors que là, on dirait qu'il est soigneusement évité.
Si on avait voulu dire que queue est une collection, on aurait
bien défini tout ce qu'il faut pour qu'elle le soit. Une des
caractèristiques de base des collections dans la STL, c'est on
puisse en accéder à tous les éléments au moyen d'un itérateur,
ce qui n'est pas le cas de queue.
En ce qui concerne la copie et l'affectation : c'est très
indirect, mais la classe présentée dans la norme les a. Fourni
par le compilateur, peut-être, mais elles y sont quand même.
Quand on veut interdire la copie, on le dit (comme dans
std::ios_base).
En revanche, évidemment, on n'hésite pas à les spécifier
explicitement dans d'autres cas, comme complex. Alors, on
pourrait arguer que c'est indéfini. Dans la mesure où on
supporte (explicitement) les opérateurs de comparaison, je doute
fort que l'intention était de ne pas permettre la copie, mais je
crois qu'effectivement, la norme n'est pas claire ici.
--
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
A partir du moment où c'est un container et à moins que cela ne soit spécifié autrement, le container a une fonction d'assignement (in l inear time).
Le problème est que je n'ai vu nulle part que queue est un container...
En effet, je ne crois pas qu'elle en est une. C'est un adaptateur de collection, et je ne vois rien qui dit qu'un adaptateur de collection soit lui aussi une collection. Au contraire, pour être une collection, il faut impérativement qu'elle définisse des types d'itérateur. (Voir table 80 dans §23.1.)
L'introduction de queue mentionne : It also provides container adaptors that make it easy to construct abstract data types, such as stacks or queues, out of the basic sequence kinds
J'ai l'impression que si on avoit voulu dire que queue est un container, on aurait pu trouver une formulation moins lourde, et où le mot container apparaît (par exemple remplacer "abstract data types" par "container"), alors que là, on dirait qu'il est soigneusement évité.
Si on avait voulu dire que queue est une collection, on aurait bien défini tout ce qu'il faut pour qu'elle le soit. Une des caractèristiques de base des collections dans la STL, c'est on puisse en accéder à tous les éléments au moyen d'un itérateur, ce qui n'est pas le cas de queue.
En ce qui concerne la copie et l'affectation : c'est très indirect, mais la classe présentée dans la norme les a. Fourni par le compilateur, peut-être, mais elles y sont quand même. Quand on veut interdire la copie, on le dit (comme dans std::ios_base).
En revanche, évidemment, on n'hésite pas à les spécifier explicitement dans d'autres cas, comme complex. Alors, on pourrait arguer que c'est indéfini. Dans la mesure où on supporte (explicitement) les opérateurs de comparaison, je doute fort que l'intention était de ne pas permettre la copie, mais je crois qu'effectivement, la norme n'est pas claire ici.
-- 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
A partir du moment où c'est un container et à moins que cela ne soit spécifié autrement, le container a une fonction d'assignement (in linear time).
Le problème est que je n'ai vu nulle part que queue est un container...
L'introduction de queue mentionne : It also provides container adaptors that make it easy to construct abstract data types, such as stacks or queues, out of the basic sequence kinds
J'ai l'impression que si on avoit voulu dire que queue est un container, on aurait pu trouver une formulation moins lourde, et où le mot container apparaît (par exemple remplacer "abstract data types" par "container"), alors que là, on dirait qu'il est soigneusement évité.
Ce n'est effectivement pas un container et il implémente seulement un subset des opérations de container ; l'opérateur de copie n'étant pas mentionné cela semble flou.
Maintenant d'après la définition d'un Container Adaptor (SGI): "... is a container adaptor, meaning that it is implemented on top of some underlying container type. By default that underlying type is deque, but a different type may be selected explicitly."
Du fait qu'il est construit autour d'un container, je pourrais supposer qu'il hérite des capacités de copie (par l'opérateur de copie implicite de l'Adaptor) du container.
Néanmoins, une personne pourrait effectivement construire une classe queue du style: template<typename _Tp, typename _Sequence> class queue { [...] protected: /** * 'c' is the underlying container. */ _Sequence c; [...] public: queue& operator=(const queue& __x) { ::memcpy(&this->c,&__x->c,sizeof(_Sequence)); //BIT COPY - avoid Container copy return *this; } [...] };
Et ne pas être en opposition avec la norme. Ce serait quand même malveillant :).
Michael
A partir du moment où c'est un container et à moins que cela ne soit
spécifié autrement, le container a une fonction d'assignement (in
linear time).
Le problème est que je n'ai vu nulle part que queue est un container...
L'introduction de queue mentionne :
It also provides container adaptors that make it easy to construct
abstract data types, such as stacks or queues, out of the basic sequence
kinds
J'ai l'impression que si on avoit voulu dire que queue est un container,
on aurait pu trouver une formulation moins lourde, et où le mot
container apparaît (par exemple remplacer "abstract data types" par
"container"), alors que là, on dirait qu'il est soigneusement évité.
Ce n'est effectivement pas un container et il implémente seulement un
subset des opérations de container ; l'opérateur de copie n'étant pas
mentionné cela semble flou.
Maintenant d'après la définition d'un Container Adaptor (SGI):
"... is a container adaptor, meaning that it is implemented on top of
some underlying container type. By default that underlying type is
deque, but a different type may be selected explicitly."
Du fait qu'il est construit autour d'un container, je pourrais supposer
qu'il hérite des capacités de copie (par l'opérateur de copie implicite
de l'Adaptor) du container.
Néanmoins, une personne pourrait effectivement construire une classe
queue du style:
template<typename _Tp, typename _Sequence>
class queue
{
[...]
protected:
/**
* 'c' is the underlying container.
*/
_Sequence c;
[...]
public:
queue& operator=(const queue& __x)
{
::memcpy(&this->c,&__x->c,sizeof(_Sequence)); //BIT COPY - avoid
Container copy
return *this;
}
[...]
};
Et ne pas être en opposition avec la norme. Ce serait quand même
malveillant :).
A partir du moment où c'est un container et à moins que cela ne soit spécifié autrement, le container a une fonction d'assignement (in linear time).
Le problème est que je n'ai vu nulle part que queue est un container...
L'introduction de queue mentionne : It also provides container adaptors that make it easy to construct abstract data types, such as stacks or queues, out of the basic sequence kinds
J'ai l'impression que si on avoit voulu dire que queue est un container, on aurait pu trouver une formulation moins lourde, et où le mot container apparaît (par exemple remplacer "abstract data types" par "container"), alors que là, on dirait qu'il est soigneusement évité.
Ce n'est effectivement pas un container et il implémente seulement un subset des opérations de container ; l'opérateur de copie n'étant pas mentionné cela semble flou.
Maintenant d'après la définition d'un Container Adaptor (SGI): "... is a container adaptor, meaning that it is implemented on top of some underlying container type. By default that underlying type is deque, but a different type may be selected explicitly."
Du fait qu'il est construit autour d'un container, je pourrais supposer qu'il hérite des capacités de copie (par l'opérateur de copie implicite de l'Adaptor) du container.
Néanmoins, une personne pourrait effectivement construire une classe queue du style: template<typename _Tp, typename _Sequence> class queue { [...] protected: /** * 'c' is the underlying container. */ _Sequence c; [...] public: queue& operator=(const queue& __x) { ::memcpy(&this->c,&__x->c,sizeof(_Sequence)); //BIT COPY - avoid Container copy return *this; } [...] };
Et ne pas être en opposition avec la norme. Ce serait quand même malveillant :).
