Discussion :

[gbdivers]

Bonjour à tous

Je me posais la question de savoir s'il était possible d'utiliser les range-based loop for sur un vecteur d'unique_ptr :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
void foo(A const& a) const {}
 
typedef std::vector< std::unique_ptr<A> > V
typedef V::const_iterator iterator;
 
V v;
 
// for(auto a : v) // error : le constructeur  par copie n'est pas valide
//    foo(a);
 
for (auto it = v.begin(); it != v.end(); ++it)
    transform(*it->get()); // ok avec un for normal
 
std::for_each(v.begin(), v.end(), [](iterator it){ foo(*it->get()); } ); // ok avec les lambdas

Remarque :
- v a la responsabilité de la destruction des éléments du vecteurs : unique_ptr
- foo() utilise simplement les éléments du vecteur : référence constante

Si quelqu'un a une idée. Merci

PS : il est possible d'utiliser "auto" dans la fonction lambda à la place de "iterator" ici ?
PS2 : au cas où, gcc 4.6.1 sous Linux 64

PS3 : encore sur l'utilisation de unique_ptr

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
// Version 1
auto a = new A;
// traitements sur a
v.push_back(std::unique_ptr<A>(a));
m.insert(std::make_pair(k, a)); // m est de type map<K,A*>
 
// Version 2
auto a = std::unique_ptr<A>(new A);
// traitements sur 
m.insert(std::make_pair(k, a.get())); // ok
v.push_back(std::move(a));
m.insert(std::make_pair(k, a.get())); // fail...

Quel est le plus sûr en terme de fuite mémoire ? en terme d'écriture ? dans le cas où les traitements ne peuvent pas lancer d'exception ? dans le cas où les traitements peuvent lancer des exception ?

De plus, a priori, il n'y a pas de fonction make_unique qui serait équivalent à make_shared. Un oubli ? Un choix volontaire ? J'ai besoin de voir un opticien ?

Merci

[Arzar]

Bonjour,

Je me posais la question de savoir s'il était possible d'utiliser les range-based loop for sur un vecteur d'unique_ptr :

Oui, bien sur !
Les range-based ne sont de toute façon pas très magiques en C++11, si je traduis la norme alors le compilateur remplace :

for ( for-range-declaration : expression ) statement

par :

for ( auto __begin = std::begin(expression),
__end = std::end(expression);
__begin != __end;
++__begin ) {
for-range-declaration = *__begin;
statement
}

(Bon ok, j'avoue avoir passé sous silence deux trois subtilités lié à l'ADL mais tout se passe comme cela)
Par example, avec le code suivant :

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
 
struct A
{
   A(int value):value(value){}
   int value;
 
};
 
void foo(const A& a)
{
   std::cout << a.value << "\n";
}
 
int main()
{
   typedef std::vector<std::unique_ptr<A>> Vec;
    Vec vec;
 
   vec.push_back(std::unique_ptr<A>(new A(1)));
   vec.push_back(std::unique_ptr<A>(new A(2)));
   vec.push_back(std::unique_ptr<A>(new A(3)));
 
  //...

Dans ce cas on a :

Code :

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

1
2
3
4
5
 
   for(std::unique_ptr<A> i : vec)
   {
       foo(*i);
   }

qui est remplacé par :

Code :

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

1
2
3
4
5
6
7
 
   for(Vec::iterator b = std::begin(vec), e = std::end(vec); e != b ; ++b) 
   {
      std::unique_ptr<A> uptr = *b;
      foo(*uptr);
   }
}

Clairement, ça ne peut pas marcher. On ne peut pas assigner un unique_ptr à un autre unique_ptr vu que tout l’intérêt d'un unique_ptr est d'être... unique

Par contre :

Code :

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

1
2
3
4
5
 
   for(std::unique_ptr<A>& i : vec)
   {
       foo(*i);
   }

donnera :

Code :

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

1
2
3
4
5
6
 
   for(Vec::iterator b = std::begin(vec), e = std::end(vec); e != b ; ++b) 
   {
      std::unique_ptr<A>& uptr = *b;
      foo(*uptr);
   }

Et la c'est OK.

[gbdivers]

Je suis très bête parfois... je n'avais même pas penser à utiliser une référence dans le for.

[oodini]

Le choix de la variable i n'est peut-être pas très heureux, même si on a l'habitude de l'utiliser dans les for. Mais parce qu'il signifie "integer" (même si après on passe à j, k...).

Je mettrai plutôt quelque chose du genre : currentElement