C++11 : Utilisation du mot clé auto

Je viens de lire toute la discussion (c++11), et bien que loin d'être au niveau pour en parler sereinement, je m'intéresse de prêt à la norme tout simplement parce que je vais être à jour avec les meilleurs outils avant de concevoir, et produire des codes avec la meilleure rigueur/propreté (qualité) possible (ce qui est loiiiin d'être le cas :) ).

J'ai quelques questions concernant le mécanisme d'inférence de type et la "redéfinition" du mot-clé auto :

Est-ce quelque chose à utiliser les yeux fermés ou est-ce que cela a été mis en place pour des cas bien spécifiques comme quand on manipule des templates par exemple ?

J'ai entendu dire que la résolution de type ne coutait pas très cher à la compilation : et sur un code d'1 million de lignes qui l'utiliserait partout ?

J'ai un peu de mal à me repérer dans la norme, donc ce n'est pas une information que j'ai réussi à trouver tout seul pour l'instant, si vous aviez en plus le paragraphe où il en est question...)

Citation:

---

Envoyé par Kaamui

Est-ce quelque chose à utiliser les yeux fermés ou est-ce que cela a été mis en place pour des cas bien spécifiques comme quand on manipule des templates par exemple ?

---

Je ne vois pas de raisons de s'en priver quand c'est plus clair.

Citation:

---

J'ai entendu dire que la résolution de type ne coutait pas très cher à la compilation : et sur un code d'1 million de lignes qui l'utiliserait partout ?

---

Si tu specifies le type explicitement, il va falloir le parser et le comparer au type de l'expression utilisee pour initialiser. Ca ne m'etonnerait pas que ce soit moins couteux de deduire le type a utiliser du type de l'expression.

Lors des récentes conférences Going Native, Herb Sutter a dit qu'actuellement ils en sont à cet avis : utilisez auto autant que vous le pouvez, sauf quand c'est plus clair d'avoir le type précis.

D'après lui et les autres du panel, il y a beaucoup d'avantages à avoir des auto autant que possible, notamment ça limite à mort le code à retoucher lors de modifications de types, qu'ils soient template ou pas.

D'ailleurs, comme le souligne Jean Marc, il y a beaucoup de cas ou tu dois répéter des types dans la même expression, le plus courant étant l'assignation par construction ou il y a le même type des deux cotés de l'opérateur. Utiliser auto simplifie à mort ce code type de code.

Citation:

---

Envoyé par Klaim

Lors des récentes conférences Going Native, Herb Sutter a dit qu'actuellement ils en sont à cet avis : utilisez auto autant que vous le pouvez, sauf quand c'est plus clair d'avoir le type précis.

D'après lui et les autres du panel, il y a beaucoup d'avantages à avoir des auto autant que possible, notamment ça limite à mort le code à retoucher lors de modifications de types, qu'ils soient template ou pas.

D'ailleurs, comme le souligne Jean Marc, il y a beaucoup de cas ou tu dois répéter des types dans la même expression, le plus courant étant l'assignation par construction ou il y a le même type des deux cotés de l'opérateur. Utiliser auto simplifie à mort ce code type de code.

---

Je n'ai pas encore vraiment regardé à auto, mais, est ce que cela veut dire qu'un code proche de

Code:

---

1 2 3 4 5 6

class MaClass { public: MaClass(auto const & rhs); auto operator = (auto const & rhs); };

---

est a priori valide :question:

@koala01: J'ai pas revérifié, mais de mémoire je crois que c'est valide si il n'y a qu'une instruction return dans le corps de la fonction, sinon c'est plus compliqué (il faut rajouter un -> decltype(/*...*/) à la fin du prototype). L'utilisation la plus directe serait pour les itérateurs. L'utilisation avec un decltype sera surment pour remplacer l'utilisation du protocole result_of.

koala01> 8O


Heu non ce n'est pas valide du tout, du moins pas dans C++11 (à ce que je sache) mais je parlais de

Code:

---

1 2	auto objet = MaClasse(); // pour faire simple

---

au lieu de

Code:

---

MaClasse objet = MaClasse(); // ça reste simple mais on imagine facilement un équivalent compliqué...

---

La syntaxe que tu indiques suppose que les fonctions avec des auto soient en fait template. Il me semble que Dave Abrahams avait proposé quelque chose comme ça pour implicitement permettre les lambda polymorphique.

Mais c'est clairement pas pour cette version ci. :aie:

@Klaim: C'est une proposition de BJ et acceptée dans cette version (*) : trailing return type. http://www2.research.att.com/~bs/C%2...#suffix-return

(*) Un peu plus complexe qu'un simple auto, mais c'est bien l'idée.

Citation:

---

Envoyé par koala01

Code:

---

1 2 3

auto operator = (auto const & rhs); };

---

---

Ça avait été proposé (par Bjarne Stroustrup et Gaby Dos Reis, si j'ai bonne mémoire), comme une manière de définir un template simplement, mais n'avait pas été retenu. Je ne sais plus précisément les raisons. Probablement trop novateur pour l'époque. Peut-être que ça reviendra dans le futur ?

Citation:

---

Envoyé par Flob90

@Klaim: C'est une proposition de BJ et acceptée dans cette version (*) : trailing return type. http://www2.research.att.com/~bs/C%2...#suffix-return

(*) Un peu plus complexe qu'un simple auto, mais c'est bien l'idée.

---

Je sais, mais je parles de la syntaxe utilisant auto en paramettre, comme le dis JolyLoic ça n'a pas été accépté.
Le trailing return type utilise utilise -> pour préciser le type, pas auto.

A en effet, j'avais pas fait attention qu'il y avait aussi un auto comme paramètre : mea culpa :aie:

Citation:

---

Envoyé par Flob90

@koala01: J'ai pas revérifié, mais de mémoire je crois que c'est valide si il n'y a qu'une instruction return dans le corps de la fonction, sinon c'est plus compliqué (il faut rajouter un -> decltype(/*...*/) à la fin du prototype). L'utilisation la plus directe serait pour les itérateurs. L'utilisation avec un decltype sera surment pour remplacer l'utilisation du protocole result_of.

---

quelque part dans le draft y'a des exemple de cela...

Citation:

---

struct A {
char g();
template<class T> auto f(T t) -> decltype(t + g())
{ return t + g(); }
};

---

...mais à quoi sert le decltype ici, plus précisément ?

Citation:

---

Lors des récentes conférences Going Native, Herb Sutter a dit qu'actuellement ils en sont à cet avis : utilisez auto autant que vous le pouvez, sauf quand c'est plus clair d'avoir le type précis.

---

- quand est-ce que c'est plus clair d'avoir le type précis ? Non parce que j'imagine un code remplis autant que possible d'auto, bah...ça allège pas la lecture quand même, ça gène personne ça ?

(par exemple, on doit reprendre un code de quelqu'un pour le faire évoluer ou le maintenir, mais quand à chaque fois qu'on appelle un itérateur il faut chercher le type en trouvant le type de la donnée...ça aide pas quand même...)

Au passage, une question sur auto.
Est-il possible d'avoir un code comme ceci ?

Code:

---

auto i = 3, s = "abc", v = &une_variable

---

Citation:

---

Envoyé par Kaamui

...mais à quoi sert le decltype ici, plus précisément ?

---

C'est le "frère" d'auto, il permet de déterminer un type à partir d'une expréssion.
Ici, on dit que le résultat de la fonction est même type que ce qui serait retourné par l'addition de ces deux objets. Ca n'execute pas l'expression, ça devine juste le type et le place à la place de decltype.

Tu peux l'utiliser dans d'autres codes que les retours de fonctions à retardement.

Citation:

---

Envoyé par Kaamui

- quand est-ce que c'est plus clair d'avoir le type précis ? Non parce que j'imagine un code remplis autant que possible d'auto, bah...ça allège pas la lecture quand même, ça gène personne ça ?

(par exemple, on doit reprendre un code de quelqu'un pour le faire évoluer ou le maintenir, mais quand à chaque fois qu'on appelle un itérateur il faut chercher le type en trouvant le type de la donnée...ça aide pas quand même...)

---

Dans les mêmes vidéos ils disent (et d'expérience je trouve aussi) que le cas le plus courant ou on a besoin de types explicitement sont en gros à chaque fois qu'on veut une conversion de type ou que l'expression avec auto ne donne pas ce que l'on veut.

Code:

---

1 2 3 4 5 6 7 8 9

auto list_entiers = { 1, 2, 3, 4 }; // ça donne std::initializer_list<int> std::vector<int> list_entiers = { 1, 2, 3, 4 }; // là c'est explicite que l'on veut plutot un vector   auto k = {42.0}; // ça donne un std::initializer_list<double> auto k{42.0f}; // maintenant c'est un float double k = 42.0f; // mais là c'est clair qu'on a un double même si on part d'un float double k = {42.0f}; // erreur! ce n'est pas une liste di'nitialization! double k{ 42.0f }; // erreur! cette syntaxe de construction ne permet pas les conversions implicites!

---

Du coup dans les cas impliquant une sorte de conversion ou une ambiguité due à la défintion de l'objet en question, il vaut mieu préciser le type.

Ekleog> Aucune idée, mais d'instinct je dirais que auto dans ce cas définis un seul type, pas plusieurs donc le compilateur refuserait de compiler tant que tu ne dis pas clairement de déterminer automatiquement le type des objets séparément.

Si c'est bien ce qui est dit dans le standard, ça serait une bonne chose parceuqe ce genre de syntaxe fais juste perdre un temps incroyable en décryptage humain. Et je parle même pas des bugs qui peuvent se cacher dans cette végétation touffue et mal entretenue. :aie:

(mon message est: ne fais pas ça ;)

Moi je me demande quel type le compilateur déciderait dans le cas suivant:

Code:

---

1 2 3 4 5 6 7

std::vector<int> une_fonction();   int main() { auto a = une_fonction(); }

---

à priori "a" serait de type std::vector<int> mais si on ne modifie pas "a" par la suite, il aurait peut être été plus judicieux qu'il soit de type std::vector<int> const& (on évite une copie).
Peut-on préciser au compilateur que l'on veut une déduction du type mais ajouter l'aspect référence "à la main", en gros déclarer "a" comme ça:

Code:

---

auto const& a = une_fonction()

---

?

Citation:

---

Envoyé par Klaim

[...]
Ekleog> Aucune idée, mais d'instinct je dirais que auto dans ce cas définis un seul type, pas plusieurs donc le compilateur refuserait de compiler tant que tu ne dis pas clairement de déterminer automatiquement le type des objets séparément.

Si c'est bien ce qui est dit dans le standard, ça serait une bonne chose parceuqe ce genre de syntaxe fais juste perdre un temps incroyable en décryptage humain. Et je parle même pas des bugs qui peuvent se cacher dans cette végétation touffue et mal entretenue. :aie:

(mon message est: ne fais pas ça ;)

---

Donc, en gros, ça alourdit la notation en plus ?
Du coup, je pense que je ne l'utiliserai que pour les noms à rallonge, comme :

Code:

---

std::unordered_map<std::string, std::pair<std::string, std::string>>::const_iterator // Exemple compliqué choisi au hasard

---

Citation:

---

Envoyé par CedricMocquillon

Moi je me demande quel type le compilateur déciderait dans le cas suivant:

Code:

---

1 2 3 4 5 6 7

std::vector<int> une_fonction();   int main() { auto a = une_fonction(); }

---

à priori "a" serait de type std::vector<int> mais si on ne modifie pas "a" par la suite, il aurait peut être été plus judicieux qu'il soit de type std::vector<int> const& (on évite une copie).
Peut-on préciser au compilateur que l'on veut une déduction du type mais ajouter l'aspect référence "à la main", en gros déclarer "a" comme ça:

Code:

---

auto const& a = une_fonction()

---

?

---

AFAIK, il n'est pas possible de prendre une référence vers un retour constant : le retour de une_fonction est un temporaire, et la référence pointerait vers n'importe quoi.
Donc la question ne se pose pas. ;)
Oups, c'est possible. Désolé ! N'empêche, je comprends mal comment ça marche ... De toute façon, en c++11 on a le move-ctor, donc la question des performances ne se pose toujours pas. ;)

Citation:

---

Envoyé par CedricMocquillon

Moi je me demande quel type le compilateur déciderait dans le cas suivant:

Code:

---

1 2 3 4 5 6 7

std::vector<int> une_fonction();   int main() { auto a = une_fonction(); }

---

---

a aurait le type T, avec T résultat de la déduction dans :

Code:

---

1 2 3

template<class T> void f(T t) {} f(une_fonction());

---

auto n'a ajouté aucune règle de déduction, il utilise les règles déjà présentes dans le langage pour les templates. De même, si tu écris auto const &a = une_fonction();, c'est équivalent à donner à a le type T const &, avec T le résultat de la déduction dans :

Code:

---

1 2 3

template<class T> void f(T const & t) {} f(une_fonction());

---

Citation:

---

Envoyé par Klaim

Code:

---

1 2 3 4 5 6 7 8 9

auto list_entiers = { 1, 2, 3, 4 }; // ça donne std::initializer_list<int> std::vector<int> list_entiers = { 1, 2, 3, 4 }; // là c'est explicite que l'on veut plutot un vector   auto k = {42.0}; // ça donne un std::initializer_list<double> auto k{42.0f}; // maintenant c'est un float double k = 42.0f; // mais là c'est clair qu'on a un double même si on part d'un float double k = {42.0f}; // erreur! ce n'est pas une liste di'nitialization! double k{ 42.0f }; // erreur! cette syntaxe de construction ne permet pas les conversions implicites!

---

---

Merci, c'est l'exemple dont j'avais besoin ;)

Et si je veux vérifier le type d'une variable comme celles-ci, après initialisation, je peux utiliser decltype, n'est-ce pas ?

une dernière question : y'a pas des risques pour le compilateur sur de la programmation répartie d'avoir un conflit non détecté entre deux portions de code qui se servent de la même variable (k) mais pour des types de donnée différents ?

Citation:

---

Et si je veux vérifier le type d'une variable comme celles-ci, après initialisation, je peux utiliser decltype, n'est-ce pas ?

---

Je ne sais pas ce que tu entends par "vérifier".

decltype te permet surtout de demander au compilateur d'utiliser le type correspondant au resultat d'une expression (qui n'est pas évaluée). Donc ça te permet d'utiliser un type sans savoir ce que c'est toi même, mais en sachant que le compilateur pourra le connaitre lors de la compilation.

Si tu veux savoir, par exemple, à dans la console quel type est utilisé, alors tu vas devior utiliser quelque chose comme typeid().

Citation:

---

une dernière question : y'a pas des risques pour le compilateur sur de la programmation répartie d'avoir un conflit non détecté entre deux portions de code qui se servent de la même variable (k) mais pour des types de donnée différents ?

---

Chaque ligne de mon exemple doit être pris comme du code totalement isolé. Il ne peut pas compiler parcequ'effectivement j'ai utilisé plusieurs fois le même nom d'objet ;)

Citation:

---

Envoyé par Eklig

Donc, en gros, ça alourdit la notation en plus ?
Du coup, je pense que je ne l'utiliserai que pour les noms à rallonge, comme :

---

les typedefs, auto et decltype sont là pour simplifier ta syntaxe ;)

Citation:

---

Envoyé par Klaim

Je ne sais pas ce que tu entends par "vérifier".

---

oui oui pardon, je parlais de pouvoir s'assurer que le type choisi était celui qu'on attendait, par exemple en renvoyant l'information sur console (du coup avec typeid() ça le fera, après tout une fois compilé, il n'y a plus d'auto dans le code).

Citation:

---

Envoyé par Klaim

decltype te permet surtout de demander au compilateur d'utiliser le type correspondant au resultat d'une expression (qui n'est pas évaluée). Donc ça te permet d'utiliser un type sans savoir ce que c'est toi même, mais en sachant que le compilateur pourra le connaitre lors de la compilation.

---

d'accord, merci...en lisant la norme je suis tombé sur des utilisations de decltype comme suit :

Code:

---

1 2 3

char g(); Template<class T>auto f(T t)->decltype(t +g())

---

et je me demande ce quel type peux renvoyer decltype avec t=MaClasse ?

Citation:

---

Envoyé par Klaim

Chaque ligne de mon exemple doit être pris comme du code totalement isolé. Il ne peut pas compiler parce qu'effectivement j'ai utilisé plusieurs fois le même nom d'objet ;)

---

Oui j'avais compris. Ma référence à k était ambigüe. Je voulais vraiment parler d'une ressource partagée par deux portions de code et qui aurait été utilisée pour deux types de données différents.


merci pour tes précisions ;)