Discussion :

[MatRem]

Bonsoir,

suite à une discussion que j'ai vu sur comp.lang.c++.moderated (http://groups.google.com/group/comp....6d29b3b6?hl=en),
je me suis effectivement aperçu qu'utiliser un conteneur de T * permettait de casser la constance.

Un exemple :

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
29
30
31
#include <list>
 
template<typename Node>
class Graph
{
	typedef std::list<std::pair<Node *, Node *> > Arcs;
 
public:
	void addArc(Node * first, Node * second) {_arcs.push_back(std::pair<Node *, Node *>(first, second));}
 
	Arcs const & getArcs() const {return _arcs;}
 
private:
	Arcs _arcs;
};
 
int main()
{
	typedef int Node;
 
	Node node0, node1;
	Graph<Node> graph;
 
	graph.addArc(&node0, &node1);
 
	Graph<Node> const & pg = graph;
 
	Node & node = *pg.getArcs().front().first; // Get a non const reference Node from a const graph
 
	node = 3; // Modify a node get from a const graph !!!
}

Je me demande si cette solution (qui semble corriger le problème) est correcte :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
template<typename Node>
class Graph
{
	typedef std::list<std::pair<Node *, Node *> > Arcs;
	typedef std::list<std::pair<Node const *, Node const *> > ArcsC;
 
public:
	void addArc(Node * first, Node * second) {_arcs.push_back(std::pair<Node *, Node *>(first, second));}
 
	ArcsC const & getArcs() const {return reinterpret_cast<ArcsC const &>(_arcs);}
 
private:
	Arcs _arcs;
};

[Médinoc]

Pour moi, ce n'est pas vraiment que ça casse la constance, mais que ça n'en ajoute pas: C'est un conteneur de pointeurs non-const.

Si tu veux, tu peux utiliser ce template:

Code C++ :

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
29
30
31
32
33
34
35
36
/*
class const_dumb_ptr:
	This class holds a pointer, but is NOT a smart pointer.
	No destruction is performed on the pointer.
	However, this class propagates const-ness to the pointer:
	when a const_ptr object is const, it becomes a pointer to const object.
 
	This class is best used for declaring class member variables, but remember
	the containing class must not manage the lifetime of more than one resource
 
This class is entirely implemented inline.
*/
template< class T >
class const_dumb_ptr
{
public:
	typedef T elem_type;
private:
	elem_type * m_ptr;
public:
	//const_dumb_ptr() {} //No default constructor: Compiler will refuse uninitialized
	const_dumb_ptr(elem_type *ptr) : m_ptr(ptr) {}
 
	elem_type * operator-> ()
	{ return m_ptr; }
	elem_type const * operator-> () const
	{ return m_ptr; }
 
	operator elem_type* ()
	{ return m_ptr; }
	operator elem_type const* () const
	{ return m_ptr; }
 
	elem_type ** operator& ()
	{ return &m_ptr; }
};

En remplaçant tes Node* par des const_dumb_ptr<Node>, la constance du conteneur devrait être propagée aux objets pointés.

[MatRem]

Oui ... c'est une autre possibilité.

En fait je ne comprends pas pourquoi les conteneurs de la STL ne font pas directement des choses comme ça (il y a sans doute quelquechose que je ne saisi pas ):

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
29
30
31
32
33
34
35
36
37
38
template<typename T>
struct ConstTrait
{
	typedef T       type;
	typedef T const const_type;
};
 
template<typename T>
struct ConstTrait<T *>
{
	typedef T *             Type;
	typedef T const * const ConstType;
};
 
 
template<typename T, typename CT = ConstTrait<T> >
class C
{
public:
	typedef typename CT::Type      Type;
	typedef typename CT::ConstType ConstType;
 
	Type      & get()       { return _val; }
	ConstType & get() const { return reinterpret_cast<ConstType &>(_val); }
 
private:
	Type _val;
};
 
int main()
{
	C<int *> c;
	c.get() = new int(3);
 
	C<int *> const & cc = c;
 
	//*cc.get() = 2; // !!Can't compile because get return a int const * const
}

[Médinoc]

Pour ce sujet, j'avais tenté un truc mais vu un problème en cas de copie du conteneur, donc j'avais renoncé...

[MatRem]

Effectivement en ajoutant le constructeur par copie on peut passer outre cette constance... Est ce le problème dont tu parles?

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
template<typename T>
struct ConstTrait
{
	typedef T       Type;
	typedef T const ConstType;
 
	static inline Type &      get     (T & i)       {return i;}
	static inline ConstType & getConst(T const & i) {return i;}
};
 
template<typename T>
struct ConstTrait<T *>
{
	typedef T *             Type;
	typedef T const * const ConstType;
 
	static inline Type &      get     (T * & i)             {return i;}
	static inline ConstType & getConst(T const * const & i) {return i;}
};
 
 
template<typename T, typename CT = ConstTrait<T> >
class C
{
public:
	typedef typename CT::Type      Type;
	typedef typename CT::ConstType ConstType;
 
	C()
	{}
 
	C(C const & c)
	:_val(c._val)
	{}
 
	Type &      get()       { return CT::get(_val); }
	ConstType & get() const { return CT::getConst(_val); }
 
private:
	T _val;
};
 
int main()
{
	C<int *> c1;
	c1.get() = new int(3);
 
	C<int *> const & c2 = c1;
 
	C<int *> c3 = c2;
 
	*c3.get() = 2; //Modify element of a container created from a const container
 
	//*c2.get() = 2; // !!Can't compile because get return a int const * const
}

Cependant, si dans le cas des Conteneur de pointeur on définit le constructeur par copie de cette manière :

Code :

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

1
2
3
C(C & c)
:_val(c._val)
{}

On ne peut copier que des conteneur non const de pointeur (donc C<int *> c3 = c2; ne compile plus). Cela règle le problème mais est ce une bonne idée?

[zais_ethael]

Huhumm, bien au delà des problèmes de constance, il y a le problème autrement plus grave de la gestion du cycle de vie.
C'est pour cela qu'on considère qu'utiliser un conteneur de pointeurs est une très mauvaise idée. Fort heureusement boost contient quelque chose pour ça: boost::ptr_container (on pourrait dire que c'est l'équivalent de conteneurs d'auto_ptr mais correctement gérés, avec interfaces appropriées et non copyables, et je pense qu'ils propagent la constance). http://www.boost.org/doc/libs/1_35_0...container.html

Si le but n'est pas de gérer le cycle de vie, tu pourrais aussi bien déclarer un conteneur de boost::reference_wrapper<X>. Ça a l'avantage d'indiquer explicitement que ça ne gère pas le cycle de vie, contrairement à ces innommables pointeurs qui n'indiquent rien du tout. Ais-je dit que c'est aussi intégré au TR1? http://www.boost.org/doc/libs/1_35_0/doc/html/ref.html

Sinon, reference_wrapper ne préserve pas la constance, d'un autre coté même quelqu'un qui connait le C++ depuis un mois et qui a appris avec un bouquin de 1992 saurait le refaire en deux minutes. Alors tu pourrais faire le tien mais qui propagerait la constance à l'objet pointé.

[MatRem]

Effectivement je comprends bien qu'il existe d'autres solutions, et que l'utilisation de pointeur de base n'est pas forcément la meilleure solution.

Il me semble quand même que, quand le conteneur n'a pas à gérer lui même la mémoire (seulement celle pour stocker les pointeurs), un conteneur de pointeur pourrait être assez pratique (plutot que de devoir passez par une classe intermédiaire).
La gestion d'un graph (cf premier message) est un bon exemple, à mon avis.

Et c'est donc pour ça que je voulais savoir pourquoi la STL ne semble pas accorder d'intérêt à ce sujet.
Peut être que c'est par souci de simplicité, ou parceque ce n'est vraiment pas une bonne idée d'avoir un conteneur de pointeurs (mais dans ce cas je ne comprends toujours pas pourquoi ).

C'est vrai qu'un pointeur tout seul n'indique pas de quel façon la mémoire vers laquelle il pointe doit être gérée, mais encapsulé dans une structure de plus haut niveau (comme un graph), ça ne me pose pas de souci, c'est plus explicite (au pire en documentant l'API).

[zais_ethael]

C'est vrai qu'un pointeur tout seul n'indique pas de quel façon la mémoire vers laquelle il pointe doit être gérée, mais encapsulé dans une structure de plus haut niveau (comme un graph), ça ne me pose pas de souci, c'est plus explicite (au pire en documentant l'API).

Ce n'est valable que si ton conteneur est totalement encapsulé dans ton conteneur de plus haut niveau, c'est à dire qu'il est inaccessible du reste du programme. Mais dans un cas pareil, qu'est ce qu'on en a à faire de la constance ?

[MatRem]

En fait je considérait mon exemple de graph comme un exemple de haut niveau ou l'utilisation d'un conteneur de pointeur n'est explicitement pas pour de la gestion d'allocation...

... et le conteneur est quand même accessible de l'éxtérieur

[zais_ethael]

Ben justement, reference_wrapper est justement fait pour indiquer explicitement qu'il n'y a pas de gestion de cycle de vie. (si on a la possibilité de spécifier ce genre de détails qui pourtant s'avèrent essentiels par l'intermédiaire de la syntaxe c'est toujours mieux que dans une documentation)

Sinon, dans ce genre de cas, tu devrais penser à concevoir un système à base d'itérateurs.