C++0x -> auto?

Bonjour à tous !

Avec l'arrivée du C++0x, et la redéfinition du mot-clef auto, je me suis posé plusieurs questions.

Est-ce que vous arriverez à indiquer quels sont les types que le compilateurs associent à ces valeurs :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

1) auto i = 0;   2) auto s = "hello";   3) auto a = {1, 2, 3, 4};   4) std::vector<int> v(10); auto i = v.begin();

---

De plus, je vous demande si vous comptez utiliser ce mot-clef? Et à quel usage? Quels sont clairement ses avantages et ses défauts?

Merci beaucoup de votre aide !

Si je ne m'abuse :
1) int
2) const char*
3) std::initializer_list<int>
4) std::vector<int>::iterator

Ce ne sont pas vraiment des cas très ambigus.

Je compte l'utiliser car ça évitera quand on bosse sur du code comportant des templates de se taper toute une ligne pour désigner un type, cf pas mal de codes de Boost.

Avantage principal : ça facilitera la vie des développeurs C++.
Inconvénient principal : il se peut que dans des situations très tordues il y ait des conflits etc. Je pense qu'on peut en trouver dans les propositions et rapports concernant 'auto' pour C++0x, dans les papiers du WG21.

Ces types sont déjà définis par le standard actuel du language:

1) int par défaut pour les constantes numériques (double pour les flottants)

2) const char* par défaut pour les string litéraux

3) 1, 2, 3 et 4 étant de type int, sauf si le prochain standard dis le contraire, ça donne un tableau natif de int : int[4] -- si les types étaient différents par contre je ne sais pas si ça aurait généré un agrégat anonyme (struct?)

4) std::vector<int>::iterator , qui est le type de l'expression -- instinctif uniquement si on a une connaissance suffisante de la STL.

Personellement je compte l'utiliser pour des temporaires variables locales de fonctions, pour du code templaté (surtout où on doit utiliser un type dépendant d'un retour de fonction membre d'un type paramettre du template), dans les boucles, dans les lambda, en fait dans tout ce qui est plus ou moins générique (et il me semble que c'est le plus grand interet).

Citation:

---

Envoyé par Alp

3) std::initializer_list<int>

---

Ah oui tiens j'avais oublié l'ajout de cette classe dans le standard.

Citation:

---

Envoyé par Klaim

Ah oui tiens j'avais oublié l'ajout de cette classe dans le standard.

---

Bah pour celui-là ça dépend, t'as peut-être raison en fait.

Citation:

---

Envoyé par Xanto

Avec l'arrivée du C++0x, et la redéfinition du mot-clef auto, je me suis posé plusieurs questions.

Est-ce que vous arriverez à indiquer quels sont les types que le compilateurs associent à ces valeurs :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

1) auto i = 0;   2) auto s = "hello";   3) auto a = {1, 2, 3, 4};   4) std::vector<int> v(10); auto i = v.begin();

---

---

Je vais répondre à ta question par un autre. Soit le code suivant :

Code:

---

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

---

Quel est le type T de t dans les cas suivants :

Code:

---

1 2 3 4 5

f(0); f("hello"); f({1, 2, 3, 4}); std::vector<int> v(10); f(v.begin());

---

La réponse est la même que celle à ta question.

Citation:

---

Envoyé par Xanto

De plus, je vous demande si vous comptez utiliser ce mot-clef? Et à quel usage? Quels sont clairement ses avantages et ses défauts?

---

Oui, je l'attends avec impatience. Peut-être pas sur les types de base, mais dès qu'il s'agit de désigner un sous type (un itérateur d'un vecteur, par exemple), sans hésiter.
De plus, il y a des types qu'il sera difficile de désigner autrement qu'avec auto (ou decltype), comme les lambdas.

Alp> Non en fait tu as bien raison, après vérification dans le document N3000 (7.1.6.4) :

Citation:

---

6 Once the type of a declarator-id has been determined according to 8.3, the type of the declared variable
using the declarator-id is determined from the type of its initializer using the rules for template argument
deduction. Let T be the type that has been determined for a variable identifier d. Obtain P from T by
replacing the occurrences of auto with either a new invented type template parameter U or, if the initializer
is a braced-init-list (8.5.4), with std::initializer_list<U>. The type deduced for the variable d is then
the deduced type determined using the rules of template argument deduction from a function call (14.9.2.1),
where P is a function template parameter type and the initializer for d is the corresponding argument. If
the deduction fails, the declaration is ill-formed. [ Example:
auto x1 = { 1, 2 }; // decltype(x1) is std::initializer_list<int>
auto x2 = { 1, 2.0 }; // error: cannot deduce element type
—end example ]

---

Donc ça serait bien initializer_list dans ce cas.

Du coup JolyLoic je me demande ce que donne

Citation:

---

f({1, 2, 3, 4});

---

A priori la réponse ne serait pas la même selon si c'est c++0x ou le standard actuel? (j'essaie de tester avec VC10 mais j'ai un bug bizarre avec, plus moyen d'editer un fichier source O__o)

Hmm malgrés ce que dis le standard, en testant ceci avec vc10 :

Code:

---

1 2 3 4 5 6 7

int wmain() { auto test = { 1, 2, 3, 4 };   return 0; }

---

J'ai une erreur : error C2078: too many initializers

Donc dans le doute j'ai ajouté :

Code:

---

#include <initializer_list>

---

Et là j'ai pas mal d'erreur en rapport avec l'implémentation d'initializer_list en plus de l'erreur précédente. Ca a pas l'air très sec tout ça... Ca donne quoi gcc?

Pour les types de bases, le sens d'auto est assez limité, c'est clair.

Cependant, pour ce cas-là :

Code:

---

1 2 3

4) std::vector<int> v(10); auto i = v.begin();

---

Le compilateur arrive à dire si c'est un const_iterator ou un simple iterator?

Citation:

---

Envoyé par Klaim

Hmm malgrés ce que dis le standard, en testant ceci avec vc10 :

Code:

---

1 2 3 4 5 6 7

int wmain() { auto test = { 1, 2, 3, 4 };   return 0; }

---

J'ai une erreur : error C2078: too many initializers

---

VC10 ne gère pas les nouvelles possibilités d'initialisation...

Citation:

---

Envoyé par Xanto

Code:

---

1 2 3

std::vector<int> v(10); auto i = v.begin();

---

Le compilateur arrive à dire si c'est un const_iterator ou un simple iterator?

---

Il s'agit d'un iterator, et non d'un const_iterator. De même, si tu écris :

Code:

---

vector<int>::const_iterator i = v.begin();

---

begin retourne quand même un iterator, qui se trouve ensuite converti en const_iterator. Le seul moyen que begin retourne un const_iterator est qu'il soit appelé sur un objet constant.

Citation:

---

Envoyé par Klaim

Ca donne quoi gcc?

---

Ça passe :)

En ce qui concerne les templates pour le nouveau standard :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#include <iostream>   template<typename T> void f(T t) { cout << t.size() << endl; }   int main() { f({1,2,3,4});   return 0; }

---

En compilant avec GCC 4.4.2, j'obtiens ceci :

Code:

---

1 2 3 4 5

g++ --std=c++0x auto.cpp -o auto auto.cpp: In function ‘int main()’: auto.cpp:19: attention : deducing ‘T’ as ‘std::initializer_list<int>’ auto.cpp:12: attention : in call to ‘void f(T) [with T = std::initializer_list<int>]’ auto.cpp:19: attention : (you can disable this with -fno-deduce-init-list)

---

C'est donc bel et bien convertit en initializer_list.

Merci beaucoup à vous tous. Je suis très content de la qualité de vos réponses, c'est exactement ce que je voulais savoir. C'est très sympa.

Le sujet est résolu. (à moins qu'il y ait plus de choses à savoir sur le mot-clef auto)

Bien sûr qu'il y a d'autres choses à savoir sur le mot-clé auto.
Il enlève les références.

Tu veux dire que :

Code:

---

1 2 3 4 5 6 7

class Machin{ /*...*/ };   Machin& test() { /*...*/ }   //...   auto k = test();

---

k est de type Machin et non Machin& ?

Oui, mais tu peux avoir :

Code:

---

1 2	auto& k = test(); // k : Machin&

---

Subtilité qui peut s'avérer importante dis donc... merci de l'info!

La régle est calqué sur celle de la déduction des arguments templates ;).

(la problématique était posé en cas de polymorphisme, notamment)

C'est ce que j'ai compris, mais j'imagine aussi tous les cas de perte de performance où des débutants utiliseraient auto a tout va et se retrouveraient avec des copies en pagaille...(avec ou sans code template)

Cela dit, dans le cas que j'ai décris, NRVO sera mis en pratique non?

En D on exactement le même auto, c'est pratique quand on a la flemme de taper le type d'une variable locale, au prix d'une certaine lisibilité. J'ai tendance à le mettre un peu partout.

Donc je suis bien content qu'il passe dans C++.

Citation:

---

Envoyé par ponce

En D on exactement le même auto, c'est pratique quand on a la flemme de taper le type d'une variable locale, au prix d'une certaine lisibilité. J'ai tendance à le mettre un peu partout.

Donc je suis bien content qu'il passe dans C++.

---

Le but de auto n'est pas d'autoriser au programmeur une flemardise de plus. Quelques fois le type d'une variable est relativement difficile à déterminer. En exemple avec les fonctions lambda - quel est le type de F dans :

auto F = [&](int a, int b, float c) -> float { return (float)((a * b) / c) }

(je crois que je l'ai écrit correctement. Sinon, vous aurez corrigé de vous même...)

(ça me semble bon en effet :p).

Mais même si je suis d'accord auto est là aussi pour s'éviter les expressions à ralonge du genre récupérer un iterator de map qui contient une paire et un string, ce genre de chose :p. (tu me diras ya les typedefs, mais quand même).
Enfin c'est certains que pour ce qui est int / vector / string je l'utilise(rai) pas..

Citation:

---

Envoyé par Goten

(ça me semble bon en effet :p).

Mais même si je suis d'accord auto est là aussi pour s'éviter les expressions à ralonge du genre récupérer un iterator de map qui contient une paire et un string, ce genre de chose :p. (tu me diras ya les typedefs, mais quand même).

---

Voui. Bon. Admettons.

Citation:

---

Enfin c'est certains que pour ce qui est int / vector / string je l'utilise(rai) pas..

---

Pour les types simples à écrire, il n'y a pas d'intérêt d'utiliser auto. En fait, ça rends le code plus complexe à déchiffrer - parce que les informations de type ne sont pas disponibles à la lecture...

Je pense que là ou ça va être vraiment utile c'est pour tout ce qui est templates un peu complexe et les agloritmes.

Citation:

---

Envoyé par Emmanuel Deloget

Le but de auto n'est pas d'autoriser au programmeur une flemardise de plus. Quelques fois le type d'une variable est relativement difficile à déterminer. En exemple avec les fonctions lambda - quel est le type de F dans :

auto F = [&](int a, int b, float c) -> float { return (float)((a * b) / c) }

(je crois que je l'ai écrit correctement. Sinon, vous aurez corrigé de vous même...)

---

exactement, et d'ailleurs dans beaucoup de papiers les exemples sont donnés en citants des boost::bind. quel est le type d'un boost::bind ?
(non ce n'est pas boost::fonction, même si c'est convertible).

que faire si tu veux stocker une reference sur std::cout par exemple ?
tu peux toujours aller chercher son type dans les headers mais pourquoi perdre du temps et de la compatibilité entre versions de la stl ?

Citation:

---

Envoyé par Emmanuel Deloget

Le but de auto n'est pas d'autoriser au programmeur une flemardise de plus.

---

Dans des langages comme ocaml, tout est "auto". Ca doit être des gros flemmards. ;)


Non, je trouve ca pratique d'écrire

Code:

---

auto myVar = 1.f;

---

au lieu de

Code:

---

float myVar = 1.f;

---

Je n'ai pas envie de donner l'information de type deux fois, ce qui fera un truc de plus à modifier le jour où j'aurais besoin de changer myVar en double.

Citation:

---

Envoyé par Lightness1024

que faire si tu veux stocker une reference sur std::cout par exemple ?

---

ostream &

Citation:

---

Envoyé par Lightness1024

exactement, et d'ailleurs dans beaucoup de papiers les exemples sont donnés en citants des boost::bind. quel est le type d'un boost::bind ?
(non ce n'est pas boost::fonction, même si c'est convertible).

que faire si tu veux stocker une reference sur std::cout par exemple ?
tu peux toujours aller chercher son type dans les headers mais pourquoi perdre du temps et de la compatibilité entre versions de la stl ?

---

ostream& comme l'a dit loic, mais ça pose aucun soucis de compatibilité... std::cout est toujours un objet static ostream...

Citation:

---

Envoyé par Goten

ostream& comme l'a dit loic, mais ça pose aucun soucis de compatibilité... std::cout est toujours un objet static ostream...

---

J'ajoute : dixit la norme ;)

Citation:

---

Envoyé par ponce

Non, je trouve ca pratique d'écrire

Code:

---

auto myVar = 1.f;

---

au lieu de

Code:

---

float myVar = 1.f;

---

Je n'ai pas envie de donner l'information de type deux fois, ce qui fera un truc de plus à modifier le jour où j'aurais besoin de changer myVar en double.

---

En même temps, tu auras plus vite retrouvé les lignes de code utilisant un float que celle contenant le caractère 'f'.

A priori, j'ai tendance à partager l'avis émis plus haut : un auto qui rend le code moins compréhensible ~bof, mais dans des cas spécifiques : template incompréhensible, lambda, où ce genre de chose : template <class T, class U> auto add(T t, U u) -> decltype(t + u) alors là, oui.

A voir aussi que ça va compliquer la tache des IDE, qui devront eux aussi deduire le type d'une variable "auto".

Il y a moyen de faire ça pas trop difficilement pour le coup. Du moins, s'ils ont accès aux internals du compilo, ils ont juste à appeler la portion du compilo qui fait l'inférence de type. Si tous les compilos proposent une option pour juste déduire le type d'une expression, ça devrait aller. Mais bon à voir si une telle chose se répandra ou pas ...

En tout cas ça ne sera pas un problème pour Visual Studio 10, ils ont justement refait complètement leur façon de gérer Intellisense de manière à "facilement" avoir les infos sur lesquelles le compilateur (aussi "nettoyé" du coup) va se baser.
Sources : le blog de la VC++ team, notemment là et là.

Citation:

---

Envoyé par Klaim

En tout cas ça ne sera pas un problème pour Visual Studio 10, ils ont justement refait complètement leur façon de gérer Intellisense de manière à "facilement" avoir les infos sur lesquelles le compilateur (aussi "nettoyé" du coup) va se baser.
Sources : le blog de la VC++ team, notemment là et là.

---

On en discutait justement avec Goten hier soir après ton message et on disait justement que les IDE qui font aussi le compilateur qui va avec vont avoir beaucoup moins de mal. A voir si gcc va offrir une option pour faire ça facilement :?

Les autres IDE pourraient utiliser… disons… une bibliothèque d'analyse de code source C++ stricte. Le genre analyseur strict, qui serait capable de jouer le rôle de front-end de compilateur.

Aaah, si seulement ça pouvait exister.

Oui ça serait tellement utile. Si seulement quelqu'un pouvait s'ateler a la tache :mouarf:

Citation:

---

Envoyé par Florian Goo

Les autres IDE pourraient utiliser… disons… une bibliothèque d'analyse de code source C++ stricte. Le genre analyseur strict, qui serait capable de jouer le rôle de front-end de compilateur.

Aaah, si seulement ça pouvait exister.

---

:roll:



ps : je parie, qu'ils attendraient d'une telle bibliothèque... qu'elle soit documentée :mouarf:

Citation:

---

Envoyé par Goten

ps : je parie, qu'ils attendraient d'une telle bibliothèque... qu'elle soit documentée :mouarf:

---

Et qui soit l'occasion de superbes tutos pour la rubrique C++ :roll:

gcc peut sortir un AST, et différents projets open source peuvent récupérer cet AST pour au choix une analyse (XOgastan) ou une sortie dans un format plus compréhensible (GCC-XML). Reste à utiliser ces outils dans les IDE courant (Faire tourner gccxml en tâche de fond requiert pas mal de puissance, notamment si le fichier C++ compilé inclut beaucoup de fichiers de la SCL par exemple. Le plus simple pour un IDE reste quand même d'avoir un parseur C++ intégré).