Discussion :

[Emmanuel Deloget]

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...)

[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).
Enfin c'est certains que pour ce qui est int / vector / string je l'utilise(rai) pas..

[Emmanuel Deloget]

(ç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.

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...

[Klaim]

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

[Lightness1024]

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 ?

[Invité]

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 :

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

auto myVar = 1.f;

au lieu de

Code :

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

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.

[JolyLoic]

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

ostream &

[Goten]

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...

[Emmanuel Deloget]

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

[3DArchi]

Non, je trouve ca pratique d'écrire

Code :

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

auto myVar = 1.f;

au lieu de

Code :

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

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.

[Kalith]

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

[Alp]

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 ...

[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à.

[Alp]

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

[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.

[Klaim]

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

[Goten]

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.

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

[3DArchi]

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

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

[Emmanuel Deloget]

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é).