Discussion :

[CedricMocquillon]

Bonjour à tous,

J'ai un petit problème avec la sémantique de déplacement émulée par boost::move (le sandbox, download). Les objets de mon projet ont tous un identifiant et un nom, vu que mes objets ont une sémantique d'entité, ils ressemblent à ça:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
class UnObjet : private boost::noncopyable
{
public:
  UnObjet(std::string const& _name, size_t const _id) : name(_name), id(_id)
  {}
 
  std::string const name;
  size_t const id;
};

C'est pratique et ça évite des erreurs. Maintenant je voudrais utiliser la sémantique de déplacement pour stocker ces objets dans une collection, j'ai donc défini un constructeur par déplacement:

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
24
25
26
27
28
 
class UnObjet : private boost::noncopyable
{
private:
  BOOST_MOVABLE_BUT_NOT_COPYABLE(UnObjet)
public:
  UnObjet(std::string const& _name, size_t const _id) : name(_name), id(_id)
  {}
 
  UnObjet(BOOST_RV_REF(UnObjet) o) : 
     name(boost::move(o.name)), id(boost::move(o.id))
  {}
 
  std::string const name;
  size_t const id;
};
 
int main(void)
{
  using namespace boost::container;
  vector<UnObjet> v;
  UnObjet o0 (0, "zero");
  UnObjet o1 (1, "un");
  v.push_back(boost::move(o0));
  v.push_back(boost::move(o1));
  assert(v.size() == 2);
  return 0;
}

Jusque là, tout va bien, mon problème c'est que si maintenant j'essaie de déplacer le vecteur que je viens de construire, le compilateur m'indique qu'il me faudrait l'opérateur "move assign" (affectation par déplacement?) et là, c'est le drame puisque du fait de mes membres const, je ne peux pas définir un opérateur "move assign".

Code :

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

1
2
3
4
5
6
 
UnObjet& operator=(BOOST_RV_REF(UnObjet) o)
{
  id = boost::move(o.id);
  return *this;
}

(Le compilateur me jette avec: l-value définit un objet const)

J'ai actuellement deux pistes pour trouver une solution:
(1) ne plus utiliser de vecteur mais des listes
(2) virer mes const, mettre mes attributs en privé et faire des accesseurs (et donc je pourrais alors définir mon move assign)

Que pensez-vous de ces solutions? Avez vous des infos sur les prérequis des conteneurs move-aware (constructible par défaut, déplaçables par copie, déplaçables par affectation, ...)?

Edit: Je viens de faire un test, une dernière possibilité est de passer par des const_cast dans l'opérateur d'affectation par déplacement:

Code :

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

1
2
3
4
5
6
7
 
UnObjet& operator=(BOOST_RV_REF(UnObjet) o)
{
  const_cast<size_t&>(id) = boost::move(o.id);
  const_cast<std::string&>(name) = boost::move(o.name);
  return *this;
}

[Arzar]

Jusque là, tout va bien

Certes, mais je ne suis pas sûr que le code fasse ce que tu avais prévu...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
#include <iostream>
struct B
{
   B(){}
   B(const B&){std::cout << "copy ctor" << std::endl;}  
   B(B&&){std::cout << "move ctor" << std::endl;}
};
int main()
{
   const B b1;
   B b2(std::move(b1));
}

Ce code affiche "copy ctor"...

A mon sens, la consteness et la sémantique de déplacement sont profondément incompatibles.

Le but de la sémantique de déplacement, c'est que l'objet cible soit construit en raflant les ressources de l'objet source, qui se retrouve vidé de sa substance et meurt. Si l'objet source est const il est impossible de le modifier, et seule sa copie est permise.

C'est ce qui se passe ici :

Code :

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

1
2
3
 
UnObjet(BOOST_RV_REF(UnObjet) o) : 
     name(boost::move(o.name))

Impossible de déplacer car o.name est const, donc le constructeur de la string se rabat sur le constructeur par copie. (et sans prévenir!).

Edit: Je viens de faire un test, une dernière possibilité est de passer par des const_cast dans l'opérateur d'affectation par déplacement:

Code :

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

1
2
3
4
5
6
7
 
UnObjet& operator=(BOOST_RV_REF(UnObjet) o)
{
  const_cast<size_t&>(id) = boost::move(o.id);
  const_cast<std::string&>(name) = boost::move(o.name);
  return *this;
}

Un cache-misère, comme souvent avec const_cast.
Ce code fait une copie de la string name, comme expliqué plus haut...

Avez vous des infos sur les prérequis des conteneurs move-aware (constructible par défaut, déplaçables par copie, déplaçables par affectation, ...)?

Il me semble que dans le draft de la nouvelle norme, les objets placés dans un vector doivent être au minimum Assignable (avoir un opérateur=), que ce soit CopyAssignable ou MoveAssignable.

[CedricMocquillon]

Merci pour ta réponse!

En fait, je n'ai peut être pas été très clair dans mon exemple (je débute en move semantic ).

Le but de la sémantique de déplacement, c'est que l'objet cible soit construit en raflant les ressources de l'objet source, qui se retrouve vidé de sa substance et meurt. Si l'objet source est const il est impossible de le modifier, et seule sa copie est permise.

Je suis d'accord avec ça, le seul truc c'est que si l'objet a des attributs const mais n'est pas constant, la sémantique de déplacement indiquant que l'objet source va être "vidé de sa substance", on serait en droit d'écrire:

Code :

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

1
2
3
4
5
 
UnObjet(BOOST_RV_REF(UnObjet) o) : 
     name(boost::move(const_cast<std::string&>(o.name))),
     id(boost::move(const_cast<size_t&>(o.id)))
  {}

pour bénéficier à la fois de la "sécurité" apportée par la constenesse des membres et l'efficacité du déplacement (ici l'optimisation portera, uniquement sur le string).

Bon par contre c'est sûr, ça oblige à utiliser un const_cast ce qui n'est pas franchement recommandé ("Un cache-misère") pour autant, je trouve que ce serait ici parfaitement justifié (n'hésitez pas à réagir sur ce point).

En gardant cette logique, l'opérateur d'affectation par déplacement deviendrait:

Code :

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

1
2
3
4
5
6
7
 
UnObjet& operator=(BOOST_RV_REF(UnObjet) o)
{
  const_cast<size_t&>(id) = boost::move(const_cast<size_t&>(o.id));
  const_cast<std::string&>(name) = boost::move(const_cast<std::string&>(o.name));
  return *this;
}

Ce qui, je l'accorde est plutôt dérangeant. Après, je reste ouvert à d'autres propositions, mais au final je me dit que soit:
(1) c'est un défaut de conception de mettre des attributs const et je dois donc mettre mes attributs en privé et faire des accesseurs m'évitant tout ces const_cast!
(2) c'est possible d'utiliser des attributs const et donc dans ce cas, si je veux pouvoir déplacer l'objet en question, vive les const_cast!

Tout éclairage est le bien venu pour trancher entre ces deux propositions...

[Goten]

Intuitivement j'aurais tendance à mettre les membres en privée et non const. D'ailleurs pas forcément assorti de l'accesseur / mutateur adéquat.
Là preuve sinon tu dois arriver à un const_cast<>. (d'un autre côté j'ai encore la tête dans le c** =) )

[gb_68]

Bonjour,
autant je comprends le constructeur (l'idée ne me semble pas incorrecte)

Code :

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

1
2
3
4
5
 
UnObjet(BOOST_RV_REF(UnObjet) o) : 
     name(boost::move(const_cast<std::string&>(o.name))),
     id(boost::move(const_cast<size_t&>(o.id)))
  {}

autant j'ai des doutes sur l'opérateur d'affectation.

Code :

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

1
2
3
4
5
6
7
 
UnObjet& operator=(BOOST_RV_REF(UnObjet) o)
{
  const_cast<size_t&>(id) = boost::move(const_cast<size_t&>(o.id));
  const_cast<std::string&>(name) = boost::move(const_cast<std::string&>(o.name));
  return *this;
}

Placer des membres en const signifie que tu ne veux plus pouvoir les modifier une fois l'objet créé. Or ici tu sembles vouloir le permettre sous pretexte que l'objet en paramètre est une r-value.

Code :

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

1
2
3
4
5
6
UnObjet  A("A",1);
// A.string == "A" et A.id == "1" 
// A.string et A.id étant const, il ne devraient plus pouvoir changer de valeur
UnObjet B("B",2);
A = boost::move(B);
// A.string == "B" ?!? et A.id == "2" ?!?

La move sémantique n'est pas sensée casser ce genre de concept existant il me semble .

[koala01]

Salut,

Peut être serait-il temps de te poser la question réelle de l'intérêt d'avoir des membres publiques constants...

En effet, tu n'es absolument pas obligé de créer des mutateurs ("setter") pour tes membres, s'il s'avère que ce n'est pas utile: si id et name ne doivent pas être modifiés une fois que ton objet est construit, rien ne t'empêche de n'exposer que des accesseurs ("getter"), et tu ne perd absolument pas au change:

• l'inlining aidant, l'accès au membre depuis un accesseur ne sera pas plus long
• La constance de l'accesseur et de la valeur renvoyée évite d'aller modifier le membre, tout en permettant malgré tout d'y accéder, en lecture, depuis un objet aussi bien constant que non constant
• Tu évites d'avoir des const_cast dans tous les coins, ce qui reste, malgré tout, souvent le symptome du fait que tu as "loupé quelque chose"
• Tu peux implémenter ta sémantique de mouvement sans aucun problème

Bref, il n'y a que du bon à l'envisager sous cet angle

Bien sur, tu pourrais me dire qu'il faut alors ajouter une paire de parenthèse chaque fois que tu souhaite accéder à un des membres de l'objet, mais, si tu t'arrête à ce genre de détail, il est peut être temps de boire une tisane à la camomille et d'aller se reposer

[CedricMocquillon]

@Goten : pour moi, un membre public const est équivalent à un membre privé avec accesseur (mais pas de mutateur du fait du const).

@gb_68 : je me serai bien passé de l'opérateur d'affectation par déplacement, le seul truc c'est que les objets d'un vecteur doivent être assignable

@koala01 : ok dans le principe, je pense effectivement me diriger vers cette solution; le seul truc c'est qu'au final je vois plus trop l'intérêt d'avoir de membre constant (dans le cas général), je suis alors tenté de l'interpréter comme une mauvaise pratique.

PS: pour koala01, j'étais en train de rédiger ma réponse à Goten et gb_68, y'a donc un peu de redite dans ma réponse par rapport à ton message

[koala01]

@koala01 : ok dans le principe, je pense effectivement me diriger vers cette solution; le seul truc c'est qu'au final je vois plus trop l'intérêt d'avoir de membre constant (dans le cas général), je suis alors tenté de l'interpréter comme une mauvaise pratique.

Il reste toujours le cas des membres statiques

Etant indépendant de toute instance de la classe, ils ne devraient pas être impliqués dans le processus de la sémantique de mouvement (à vérifier avec ce que dit C++0x à ce sujet )

[gb_68]

@gb_68 : je me serai bien passé de l'opérateur d'affectation par déplacement, le seul truc c'est que les objets d'un vecteur doivent être assignable

C'est vrai que tu l'as introduit à cause de la contrainte que les vecteurs t'imposaient (Assignable).

Mais devoir passer outre le const pour pouvoir utiliser les vecteurs, c'est pas génial comme solution (l'opérateur étant ensuite disponible dans tout le reste du code).
Le même problème survient quand l'objet possède des références : on ne peut pas définir un opérateur d'affectation correcte.

Les vecteurs auront surtout besoin d'un constructeur par déplacement (qui remplacera celui par copie, actuellement nécessaire) et du destructeur lors de l'expansion/la réduction de ceux-ci.
L'opérateur d'assignement doit sans doute être requis pour le déplacement interne des objets dans le vecteur (avec erase par exemple). C'est dommage que cette contrainte reste pour les vecteurs...

Cela aurait pu être également réalisé par destruction puis placement new (peut être moins performants). Mais cela est aussi moins exception safe.

[Médinoc]

Un objet qui peut avoir des membres const ne devrait pas être assignable (ou du moins, ne devrait pas tenter de modifier ces membres-là lors d'une assignation).

[gb_68]

Je viens de mieux comprendre la "move" sémantique. En fait un objet qui a été déplacé n'est pas détruit pour autant. Il est dans une sorte d'état "vide" (encore que - je n'ai toujours pas compris le swap dans l'implémentation d'exemple de l'opérateur= rvalue ref. vue aussi ici [Edit] c'est peut être une erreur -> l'operator= par copie est aussi buggé [/Edit]).
Cet objet vide doit supporter le destructeur de la classe ainsi que l'opérateur d'affectation - au vu de la nouvelle implémentation du swap.

Code :

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

1
2
3
4
5
6
template <class T> swap(T& a, T& b)
{
    T tmp(std::move(a));
    a = std::move(b);   
    b = std::move(tmp);
}

Le fait de pourvoir modifier une rvalue référence (par exemple pour "vider" l'objet) rend inéligible à la move sémantique tout objet qui possède un membre non mutable, tel que const ou référence.

[Médinoc]

Le fait de pourvoir modifier une rvalue référence (par exemple pour "vider" l'objet) rend inéligible à la move sémantique tout objet qui possède un membre non mutable, tel que const ou référence.

En es-tu sûr?
On peut faire une move semantic sans modifier tous les membres de l'objet source. Généralement, on ne modifie que les membres qui référencent une ressource...

[gb_68]

En es-tu sûr?

Non .

On peut faire une move semantic sans modifier tous les membres de l'objet source. Généralement, on ne modifie que les membres qui référencent une ressource...

Oui ce serait possible, mais cela donnerait des effets surprenants. Il serait possible de réaliser un swap entre ces deux objets, qui verraient une partie de leurs membres échangés mais pas l'autre.
Je pense que ce serait comme écrire - actuellement - un constructeur par copie qui modifie l'objet à copier ; ce n'est une pratique correcte que dans très peu de cas (ex. auto_ptr, mais justement bientôt remplacé par unique_ptr).