Discussion :

[moldavi]

Re.

Tout ce qui compte, c'est de savoir que c'est une position dans un conteneur. Et que je peux lui appliquer les opérations que l'on peut appliquer à toutes les positions dans ce type de conteneur. Et ça, je le sais en regardant comment la variable est initialisée. auto i = maListe.begin(); me semble bien plus claire que si on devait préciser le type. D'ailleurs, je suis certain que tu as compris de quoi je parlais, alors même que tu ne sais pas quel est le type de maListe.

Tout cette démonstration, je l'approuve, j'ai même dis dans un message précédent que auto dans un une boucle sera utile, au vu du verbiage C++.

C'est le auto à toute les sauces qui est un non sens. Avec auto, vous n'avez pas besoin de mettre la souris sur la variable, pour savoir ce que c'est. Vous êtes vraiment des génies...

[bacelar]

On n'est pas des génies, on porte l'attention sur l'algorithmie, il faut juste que les types suivent.

[jo_link_noir]

Pourquoi for(a : b), ce n'est pas foreach(a in b) ??

Par ce qu'introduire un nouveau mot clef est très risqué: problème de compilation. Un code utilisant decltype ou noexcept pour des noms de variables/fonctions, n'est pas compilable en C++11 (pas de problème avec final ou override, leur ajout est sans ambiguïté).
Alors ajouter des mots couramment utilisés comme 'in' ou 'foreach' est impossible sans casser de nombreux codes.

Et non, std::for_each et for(T a:c) ne sont pas pareil. Le premier est une fonction qui prend des itérateurs comme n'importe quel algorithme de la sl. Le second est du sucre syntaxique qui fonctionne sur des containers (plus précisément un type qui supporte std::begin(T&)/std::end(T&)). Et pas besoin d'être un génie pour comprendre la boucle.

Note que C++ n'est pas le seul à proposer for pour boucler sur une collection: bash, javascript, ruby, etc. Et même si la plupart utilisent en plus 'in', ce n'est pas le cas de tous : D, php, Go, Scala.
(En cherchant pour ruby je suis tombé sur ça: https://en.wikipedia.org/wiki/Foreach_loop, certain n'ont même pas de mot définit pour faire un foreach ).

[moldavi]

Bonjour jo_link_noir.

Par ce qu'introduire un nouveau mot clef est très risqué: problème de compilation.
Alors ajouter des mots couramment utilisés comme 'in' ou 'foreach' est impossible sans casser de nombreux codes.

C'est marrant parce que "foreach", "in", cela va casser de nombreux code, mais "auto", non... Je ne suis malheureusement pas convaincu par l'argument. Une boucle avec "foreach in" est mentalement compréhensible par n'importe qui. Si cela peut rendre le C++ plus abordable, je suis pour.

Un code utilisant decltype ou noexcept pour des noms de variables/fonctions, n'est pas compilable en C++11 (pas de problème avec final ou override, leur ajout est sans ambiguïté).

Désolé, je ne comprends pas où tu veux en venir et le rapport avec le reste.

Et non, std::for_each et for(T a:c) ne sont pas pareil. Le premier est une fonction qui prend des itérateurs comme n'importe quel algorithme de la sl. Le second est du sucre syntaxique qui fonctionne sur des containers (plus précisément un type qui supporte std::begin(T&)/std::end(T&)). Et pas besoin d'être un génie pour comprendre la boucle.

Il y a méprise. J'ai parlé de génie pour les personnes qui n'ont pas besoin de mettre la souris sur une variable auto pour connaître le type exact. Rien à voir avec les boucles.

Note que C++ n'est pas le seul à proposer for pour boucler sur une collection: bash, javascript, ruby, etc. Et même si la plupart utilisent en plus 'in', ce n'est pas le cas de tous : D, php, Go, Scala.
(En cherchant pour ruby je suis tombé sur ça: https://en.wikipedia.org/wiki/Foreach_loop, certain n'ont même pas de mot définit pour faire un foreach ).

Est-ce vraiment un argument ? Les autres le font alors ce n'est pas grave...

C'est vrai qu'au bout de plusieurs utilisations, un for(A : B) deviendra naturel. Mais un foreach(A in B) l'est cent fois plus. Si des choses du langage permettent de coller au mental de l'homme, pourquoi ne pas le faire. Les débutants se sentiront plus à l'aise.

[gl]

C'est marrant parce que "foreach", "in", cela va casser de nombreux code, mais "auto", non... Je ne suis malheureusement pas convaincu par l'argument.

auto était déjà un mot clé du langage, donc non utilisé pour nommé une variable, un fonction ou autre. Et n'était quasiment pas utilisé en pratique (car inutile). Il est possible que du code ait été cassé mais de manière marginale, et en tout cas moins que si on avait utilisé un autre mot clé. Et probablement moins que ce qu'aurait cassé l'usage de foreach ou de in.

J'ai parlé de génie pour les personnes qui n'ont pas besoin de mettre la souris sur une variable auto pour connaître le type exact.

Je suis ravi d'apprendre que je suis un génie . Plus sérieusement, oui il m'arrive lors de l'usage d'une variable "auto" de mettre la souris pour connaitre son type, mais c'est aussi vrai pour les autres.

D'une part, et c'est la remarque de Loïc, je n'ai bien souvent pas besoin de connaitre le type précis d'une variable, seulement les services qu'elle rends.
D'autre part, pour les variables auto, le type n'est certes pas déclaré mais apparait lors de sa déclaration au travers de la valeur d'initialisation.

C'est vrai qu'au bout de plusieurs utilisations, un for(A : B) deviendra naturel. Mais un foreach(A in B) l'est cent fois plus. Si des choses du langage permettent de coller au mental de l'homme, pourquoi ne pas le faire. Les débutants se sentiront plus à l'aise.

Au bout de plusieurs utilisation ! Tu plaisantes, une devrait suffire à quelqu'un de raisonnablement intelligent et disposant d'un minimum de vernis C++. Après tout for est déjà ce qui permet d'itérer sur un ensemble de valeur.
foreach(A in B) l'est certes un peu plus, mais la différence est minime. Et ce n'est certainement pas ce qui rends le langage difficile d'accès.

[nikko34]

Il faut voir "auto" en conjonction avec les templates.

Quand on écrit une fonction template:

Code :

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

1
2
3
4
5
6
 
template< typename T >
void maFonction( T & maVariable )
{
    maVariable.vasy();
}

Est-ce que quelqu'un est choqué de ne pas connaître le type de maVariable? non. Il faut juste que le type ait une fonction nommé "vasy" et ça compile, c'est tout ce qu'on lui demande.

Donc quand on a l'habitude de ce code là (un des gros intérêt du C++), on comprend tout de suite l'intérêt du "auto", si on a par exemple:

Code :

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

1
2
3
4
5
6
 
template< typename T >
typename T::type_de_retour maFonction( T & maVariable )
{
    return maVariable.vasy();
}

On peut passer n'importe quel objet à maFunction, il faut qu'il réponde au contrat:
- J'ai une fonction vasy
- J'ai un "type_de_retour"

Toute la librairie C++ est sur ce principe (on est pas obligé de tout comprendre pour l'utiliser). Du coup l'utilisateur peut faire un simple

Code :

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

1
2
 
auto ret = maFonction( monObjet );

Sans être obligé de voir tous les rouages de la lib en dessous.

Pour le for_each:

Sinon pour le coup du "in", c'est assez simple: si on rajoute un mot clé "in", alors tous les codes qui utilisent "in" comme nom de variable ou nom de fonction vont être cassés. Alors que ":" et "auto" faisaient déjà partis des mots clés interdits.

for_each correspond à la norme d'écriture de la lib C++. Son but principal était d'appeller une fonction ou un functor sur chaque élement d'un container.

[moldavi]

Bonjour nikko34.

Je ne suis pas contre auto dans les boucles (verbiage de la STL), je ne suis pas contre auto pour le développement de bibliothèques comme la STL. Je suis inquiet des déviations sur son utilisation, et pour la revue de code (code fonctionnel, pas le code d'une bibliothèque). Je suis pour l'évolution du C++, mais je pense que auto sera problématique. Et si je ne dis pas de bêtise, auto était dans les cartons, mais a mis des années avant de voir le jour (il y avait des gens sensés dans le C++...). Je pense qu'il devrait rester dans les cartons. On peut faire largement sans, d'autant plus à l'heure des "intellisense".

auto facilite le travail du développeur (vous avez l'air tous ravi), mais pas le travail de maintenance (le plus important dans la vie d'un logiciel). Un code doit être KISS, et auto ne va pas dans ce sens.

La première déviation, quelqu'un en a fait part ici. Utiliser auto pour déclarer un int... Pour le coup ce n'est pas très malin, parce que int c'est 3 lettres et auto c'est 4.

Code :

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

1
2
 
auto ret = maFonction( monObjet );

Imaginons que je fais une revue de code pour la première fois. Je ne connais pas maFonction, et effectivement on s'en fout de savoir ce qu'elle fait. Par contre je n'ai aucun renseignement visuel parce que auto je ne sais pas ce que c'est. Je met ma souris sur auto et disons que c'est le type IMaSuperInterface. Je regarde ce que fait cette interface, ok.

5 minutes plus tard je tombe sur ce code :

Code :

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

1
2
 
auto ret = maFonction2( monObjet );

Je ne connais pas maFonction2 et encore moins auto. Rebelotte, la souris. Ah mais je connais déjà cette interface, c'est la même que tout à l'heure...

Si le code avait été :

Code :

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

1
2
 
IMaSuperInterface ret = maFonction2( monObjet );

Pas besoin de chercher plus loin, d'un coup d'oeil, je sais où l'on va, sans connaître maFonction2 (on s'en fout, c'est vrai). Je peux continuer la revue de code sans mouvement de souris, et crâmage de neurone inutile.

Lorsque je fais de la revue de code pendant 2 heures d'affilée, je remercie le développeur de ne pas avoir mis auto à toutes les sauces.

[gl]

auto facilite le travail du développeur (vous avez l'air tous ravi), mais pas le travail de maintenance (le plus important dans la vie d'un logiciel). Un code doit être KISS, et auto ne va pas dans ce sens.

Je pense précisément le contraire. auto facilite un peu le travail du développeur mais ça ne va pas le révolutionner. Par contre il va effectivement facilité la maintenance.

La première déviation, quelqu'un en a fait part ici. Utiliser auto pour déclarer un int... Pour le coup ce n'est pas très malin, parce que int c'est 3 lettres et auto c'est 4.

Mais pourquoi tu te focalises (ce n'est pas la première fois) sur le nombre de lettre ? ce n'est pas ce qui est important. Et certainement pas ce qui fait l'intérêt premier de auto.

Imaginons que je fais une revue de code pour la première fois. Je ne connais pas maFonction, et effectivement on s'en fout de savoir ce qu'elle fait. Par contre je n'ai aucun renseignement visuel parce que auto je ne sais pas ce que c'est. Je met ma souris sur auto et disons que c'est le type IMaSuperInterface. Je regarde ce que fait cette interface, ok.

5 minutes plus tard je tombe sur ce code :

Code :

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

1
2
 
auto ret = maFonction2( monObjet );

Je ne connais pas maFonction2 et encore moins auto. Rebelotte, la souris. Ah mais je connais déjà cette interface, c'est la même que tout à l'heure...

Si le code avait été :

Code :

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

1
2
 
IMaSuperInterface ret = maFonction2( monObjet );

Pas besoin de chercher plus loin, d'un coup d'oeil, je sais où l'on va, sans connaître maFonction2 (on s'en fout, c'est vrai). Je peux continuer la revue de code sans mouvement de souris, et crâmage de neurone inutile.

Ben s'il est important de savoir de quel type est ta variable, tu n'utilises pas auto mais tu déclares son type. Je ne vois pas ce qui pose problème.
auto est un outil parmi d'autres. Tu l'utilises lorsqu'il est utile, et tu en utilises un autre lorsque tu as besoin d'autre chose (et lorsque tu veux que ta variable soit du type d'une interface et non du type concret, tu as besoin d'autre chose).

En te lisant, j'ai l'impression que plus que l'introduction de l'inférence de type, ce que tu reproches à auto c'est de rajouter un nouvel outil à la boute à outil qu'est le C++ et de te laisser faire le choix de l'outil à utiliser plutôt que de le faire pour toi et de te l'imposer (quitte à ce que cet outil imposé ne soit pas celui dont tu as vraiment besoin.

Lorsque je fais de la revue de code pendant 2 heures d'affilée, je remercie le développeur de ne pas avoir mis auto à toutes les sauces.

Pour en faire assez régulièrement, je n'ai pas vu d'impact significatif sur la durée ni sur la difficulté à faire des revues de code du fait de l'usage d'auto.

Ca vient peut être de la façon dont je fais des revues (déjà, il est rare que je fasse deux heures d'affilé. En gros, on applique le principe d'une revue par responsabilité/brique/module/etc. et donc plusieurs revues assez courtes plutôt qu'une revue monolithique de plusieurs heures qui aborde des dizaines de fonctionnalités différentes) mais avec un découpage correct du code et un nommage explicite des variables et fonctions, l'absence de type déclaré ne me pose pas de problème dans la majorité des cas, bien au contraire (et dans la minorité restante, ben on déclare le type tout simplement).

[moldavi]

Bonjour gl.

auto était déjà un mot clé du langage, donc non utilisé pour nommé une variable, un fonction ou autre. Et n'était quasiment pas utilisé en pratique (car inutile). Il est possible que du code ait été cassé mais de manière marginale, et en tout cas moins que si on avait utilisé un autre mot clé. Et probablement moins que ce qu'aurait cassé l'usage de foreach ou de in.

Argument indéniable pour auto (merci pour la précision) mais insuffisant. Je n'ai certes pas vu tous les codes sources C++ de la planète, mais des "foreach"/"in", je n'en ai jamais vu dans du code C++. Le cassage de code source avec "foreach"/"in", je ne l'avalerai pas sans preuve. J'attends toujours les liens de milliers de code source potentiellement vulnérable à cette update...

D'une part, et c'est la remarque de Loïc, je n'ai bien souvent pas besoin de connaitre le type précis d'une variable, seulement les services qu'elle rends.

Donc lorsque tu vois auto, tu sais déjà les services rendus par auto. Des génies, vous êtes. Quand je vois auto, je ne vois rien, parce que cela ne veut rien dire. Par contre lorsque je vois IMaSuperInterface, là je sais que la variable fait de supers choses...

D'autre part, pour les variables auto, le type n'est certes pas déclaré mais apparait lors de sa déclaration au travers de la valeur d'initialisation.

C'est vrai, c'est le cas "normalement" le plus fréquent. Le cas des "template" (cf post précédent) montre un autre cas, et le "auto i" en place de" int i" un autre. Le cas des 95%, c'est cool, j'attends toujours la démonstration.

Au bout de plusieurs utilisation ! Tu plaisantes, une devrait suffire à quelqu'un de raisonnablement intelligent et disposant d'un minimum de vernis C++. Après tout for est déjà ce qui permet d'itérer sur un ensemble de valeur.
foreach(A in B) l'est certes un peu plus, mais la différence est minime.

La différence est loin d'être minime. Tout ce qui colle au mental sera compréhensible, sans connaissance experte du langage.

[gl]

Le cassage de code source avec "foreach"/"in", je ne l'avalerai pas sans preuve. J'attends toujours les liens de milliers de code source potentiellement vulnérable à cette update...

Il n'y en a sans doute pas des milliers, mais ils existent (pour foreach au moins, j'en suis sur. Certains aiment bien redévelopper la bibliothèque standard, mais sans utiliser sa politique de nommage).
Et même il n'y en aurait qu'un, c'est toujours un de plus que tu casses en utilisant foreach/in plutôt que for( : )

Donc lorsque tu vois auto, tu sais déjà les services rendus par auto. Des génies, vous êtes. Quand je vois auto, je ne vois rien, parce que cela ne veut rien dire. Par contre lorsque je vois IMaSuperInterface, là je sais que la variable fait de supers choses...

Les variables ont aussi (et surtout) un nom ! Et lorsque les gens nomment à peu prés correctement les choses, ce nom indique son rôle et donc les services qu'elle rend.
Et étrangement, ce nom m'apprends souvent bien plus de choses que de connaitre le type précis. D'autant que contrairement au type il apparaît aussi lorsque j'utilise ladite variable et pas uniquement lorsque je la déclare.

Et dans les cas où le type est réellement important, ben je le déclare. Mais ça ne m'empêche pas d'utiliser auto le reste du temps ni ne me fais cracher sur celui-ci.

C'est vrai, c'est le cas "normalement" le plus fréquent.

Si tu utilises auto, tu as forcément une valeur d'initialisation, ce n'est pas juste "normalement le plus fréquent).

Le cas des "template" (cf post précédent) montre un autre cas

Les règles de déduction de type sont similaire entre template et auto. Mais à part ça je ne vois ce que viennent faire les templates par rapport à la phrase que tu cites.

et le "auto i" en place de" int i" un autre.

Je ne vois pas de différence fondamentale entre int et un autre type en ce qui concerne l'usage d'auto. Du coup je ne vois pas quel cas particulier tu cherches à mettre en évidence.

La différence est loin d'être minime. Tout ce qui colle au mental sera compréhensible, sans connaissance experte du langage.

Je pense que là, on a une vrai divergence de point de vue. Je n'estime pas que la connaissance de la syntaxe de base d'un langage est "un connaissance experte du langage". Et la signification de for( : ) est de la syntaxe de base.

Et au passage, foreach/in, au moins dans mon cas, ne "colle pas plus au mental" que for( : ) (j'ai malheureusement tendance à penser et à réfléchir en français).

[Neckara]

Bonjour,

Personnellement, j'utilise surtout auto pour les itérateurs :

Code :

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

1
2
std::map<MaClasseA, MaClasseB>::iterator it = maMap.begin();
auto it = maMap.begin();

Je n'ai en aucun cas besoin de connaître le type exact de it, je sais que c'est un itérateur, et cela me suffit.
De plus, si je remplace ma std::map par une std::unordered_map, mon code ne changera pas.

On peut aussi s'en servir pour les retours de fonctions templates :

Code :

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

1
2
3
4
template <typename T, typename U>
auto foo(T, U) -> decltype(T+U)
{
}

Alors, oui, on ne connaît pas le type de retour de la fonction, ce qui est un peu normal vu qu'il change en fonction des paramètres templates.

Pour le reste, je n'utilise pas auto.
J'utilise decltype pour les templates :

Code :

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

1
2
3
4
auto it = container.begin();
using Element = decltype( *it );
 
Element element  = *it;

Bon, je recherche encore comment obtenir un A au lieu d'un A& .

Donc voilà, auto ne me pose aucun problème dans mon code.
Je l'utilise pas à chaque ligne, c'est tout. Après, c'est comme goto, si des personnes l'utilisent n'importe comment, ce n'est pas sa faute mais bien celle des développeurs.
Et ce n'est pas parce qu'on ne l'utilise pas tous les jours qu'il ne sera pas utile à un collègue dans l'embarqué ou autre.

Pour for( Element e : container), je pense qu'il ne faut pas exagérer, cela ne prend que quelques secondes à l'assimiler et à le retenir.
Pour foreach( e in c), je me demande si :

Code :

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

void foo(std::istream & in, std::ostream & out);

Compilerait encore...

[nikko34]

et encore, on a pas parlé des lambdas...

mais bon après, on utilise auto si on veut ou pas, on est pas obligé. Je ne vois personnellement pas ce que ça change si on a l'habitude d'utiliser des templates et de pouvoir passer d'un container à un autre sans modification de code.

On parle de auto à la place de int dans un exemple, mais généralement c'est plutôt à la place de std::vector< std::map< std::string, std::vector< std::string > > >::iterator

[JolyLoic]

Un exemple où un auto entier m'a aidé ? Passage en 64 bits d'un code contenant à la fois des collections STL et des collections maisons que l'on vire peu à peu où les indices et tailles étaient gérées en signed int. Donc en gros plein de confusions et de casts entre int, size_t, unsigned_int, long, unsigned long....
Quand je vois :

Code :

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

int elementCount = maCollection.size();

Je n'ai aucune idée si le code en question est correct ou pas, et s'il va le rester.
Si à la place j'ai

Code :

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

auto elementCount = maCollection.size();

Je sais que mon code est forcément correct. L'équivalent

Code :

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

TypeDeMaCollection::size_type  elementCount = maCollection.size();

Me semble moins intéressant, car il m'impose de connaitre le type exact de ma collection, alors que celui-ci peut varier au cours des refactorings.

[jblecanard]

Bon, je recherche encore comment obtenir un A au lieu d'un A& .

std::remove_reference ou std::decay en poussant la logique jusqu'au bout. Utilisé directement, c'est chiant à écrire, mais on peut être astucieux :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#include <vector>
#include <string>
#include <type_traits>
 
template <typename T> auto decay(T) -> typename std::decay<T>::type;
 
int main() {
  std::vector<std::string> v = {"a","b","c"};
  auto it = begin(v);
  using Element = decltype(decay(*it));
  return std::is_same<Element, std::string>::value ? 0 : 1;
}

[moldavi]

Bonjour gl.

Je pense précisément le contraire. auto facilite un peu le travail du développeur mais ça ne va pas le révolutionner. Par contre il va effectivement facilité la maintenance.
).

Il va "effectivement faciliter la maintenance". Un début d'argument serait le bienvenu.

Mais pourquoi tu te focalises (ce n'est pas la première fois) sur le nombre de lettre ? ce n'est pas ce qui est important. Et certainement pas ce qui fait l'intérêt premier de auto.

Si le nombre de lettre n'est pas fondamental, alors pourquoi ne pas écrire le type exact de la variable ?

Vous me dîtes, j'utilise "MaFonction" de la bibliothèque toto, et je ne sais pas ce qu'elle fait. J'utilise donc auto parce que je ne connais pas le type de retour. Bon là vous n'êtes plus des génies, mais des Dieux... (ne le prenez pas mal pour vous tous, j'ai beaucoup d'humour).

Lorsque l'on développe, on sait où l'on va. Si on utilise une bibliothèque, on connait ses services et sa valeur de retour. Alors auto est-il vraiment indispensable, si ce n'est pour gagner quelques lettres à écrire dans le designer...

auto dans une boucle, je vois bien l'avantage par rapport à "std::vector<...const_iterator" (une faiblesse du C++), et pour les développeurs de bibliothèques type STL. Je signale juste les déviations possibles. Donc je me pose la question de sa pertinence, et j'ai répondu. Cela n'engage que moi. Sinon pourquoi auto est-il resté si longtemps dans les cartons ?

Le C++ fait sa vie et j'apprécie son évolution, même si...

Cela m'attriste de lire que le C++ serait victime de son passé. Je fais plus du "C with classes" que du "C++ Modern". Et pour cause, le "C with classes" est d'une simplicité étonnante. Il permet de se concentrer sur d'autres choses plus complexes (hors langage). Le multi-casquette du langage C++ est une bonne chose, mais ne venez pas m'expliquer que le C++, c'est uniquement du "C++ Modern". Le C++ c'est plein de chose à adapter selon les cas.

Lorsque l'on fait du "C with classes" (c'est quand même du C++...), on peut faire des programmes simples à lire, sécurisés et performants.

Que le C++ permette d'aller plus loin, c'est très bien, et c'est la force du C++.

Ce que je n'aime pas ici, de la part de nombreux intervenants, c'est venir nous expliquer que le C++, c'est le "C++ Modern" et rien d'autre. J'ai les arguments pour expliquer que le "C with classes" à encore sa place...

Le C++ est multi paradigme. On utilise les "template" ou pas, les "auto" ou pas, les hiérarchies" à 10 étages ou pas. On utilise le plus simple selon nos besoins. C'est la force du C++. Son passé est sa force.

[jo_link_noir]

Si le nombre de lettre n'est pas fondamental, alors pourquoi ne pas écrire le type exact de la variable ?

Vous me dîtes, j'utilise "MaFonction" de la bibliothèque toto, et je ne sais pas ce qu'elle fait. J'utilise donc auto parce que je ne connais pas le type de retour.

L'important n'est pas de savoir si oui ou non on connaît le type de retour, mais de savoir si connaître le type est utile. La plupart du temps non car le nom de la variable et l'expression de droite suffisent à comprendre son rôle et donc les services qu'elle rend.

Autre chose, si par exemple une fonction retourne un autre type mais proposant les même services il faudra repasser partout. Pas avec auto.

Ce que je n'aime pas ici, de la part de nombreux intervenants, c'est venir nous expliquer que le C++, c'est le "C++ Modern" et rien d'autre. J'ai les arguments pour expliquer que le "C with classes" à encore sa place...

Lesquels ?
Par ce que ne pas utiliser auto n'en fait pas du "C avec classes"...

[gl]

Il va "effectivement faciliter la maintenance". Un début d'argument serait le bienvenu.

Pour commencer, je te renvoies aux messages de Loïc concernant la récupération de la taille d'un conteneur ou d'un itérateur sur celui-ci.

L'autre gros avantage de auto c'est qu'il type correctement (ce que bien peut de personne font correctement à la main et qui n'est pas détecter par le compilateur à cause de la palanqué de conversions implicites, malheureusement), le cas du int pour récupérer la taille d'un objet ou le nombre d'élément est assez symptomatique de ce fait. L'usage de auto va mécaniquement limiter les problèmes de portage dans ce cas de figure.

Et encore une fois, dans pas mal de cas je n'ai pas besoin de connaître précisément le type d'une variable juste ce qu'elle fait. Et là auto convient très bien et ne m'oblige pas à rentrer dans le détail du type à la lecture du code tant que je n'en ai pas besoin.

Si le nombre de lettre n'est pas fondamental, alors pourquoi ne pas écrire le type exact de la variable ?

Car écrire le type exacte ne m'apporte rien. Car écrire le type exacte rends le code moins générique ou moins "auto adaptable" (et donc moins robuste) au changement. Car le compilateur type souvent mieux que moins (il est par exemple fréquent que j'utilise -et vu les codes que je lis je suis loin d'être le seul - size_t pour récupérer le nombre d'éléments d'un conteneur).

En outre, j'ai dit que le nombre de lettres n'est pas l'argument premier pour l'usage de auto, et je persiste (ça aurait "var" ou "decltype" que je l'utiliserais autant). Il n'en reste pas moins vrai qu'il m'est plus agréable d'écrire et de lire auto que le type exacte d'un itérateur.

Lorsque l'on développe, on sait où l'on va. Si on utilise une bibliothèque, on connait ses services et sa valeur de retour.

Dans un grand nombre de cas, les services et les contrats me suffisent. Le type est accessoire.
Que l'on regrette l'absence de support natif des contrats et des concepts actuellement en C++, c'est une chose (et je fais parti des gens qui le regrette. Mais que l'on regrette la présence d'intéférence de type en est une autre que je ne comprends pas.

Alors auto est-il vraiment indispensable, si ce n'est pour gagner quelques lettres à écrire dans le designer...

Indispensable, non. D'ailleurs on a fait sans pendant très longtemps.
Plus agréable, plus confortable, certainement. Plus robuste, oui aussi, ne serait-ce que pour la gestion des tailles et des itérateurs.

auto dans une boucle, je vois bien l'avantage par rapport à "std::vector<...const_iterator" (une faiblesse du C++), et pour les développeurs de bibliothèques type STL.

Oui mais pas uniquement. Il y a nombre d'autres cas où il est intéressant. Le remplacement des itérateurs est juste le cas le plus évident.

Je signale juste les déviations possibles. Donc je me pose la question de sa pertinence, et j'ai répondu. Cela n'engage que moi. Sinon pourquoi auto est-il resté si longtemps dans les cartons ?

Juste les déviations ! Pourtant n'est ce pas toi qui a écrit :

le mot clé "auto" du C++ ne devrait pas exister...

Encore une fois l'objet n'est pas d'utiliser auto pour toutes déclarations ni de transformer le C++ en langage en typage dynamique [1]. Mais juste d'avoir un outil de plus dont l'intérêt est réel et va bien au delà de simplement remplacer la déclaration de type des itérateurs.

Cela m'attriste de lire que le C++ serait victime de son passé. Je fais plus du "C with classes" que du "C++ Modern". Et pour cause, le "C with classes" est d'une simplicité étonnante. Il permet de se concentrer sur d'autres choses plus complexes (hors langage). Le multi-casquette du langage C++ est une bonne chose, mais ne venez pas m'expliquer que le C++, c'est uniquement du "C++ Modern". Le C++ c'est plein de chose à adapter selon les cas.

Oui il y a plusieurs dialecte dans le C et oui je trouve ça bien. Et je ne pense pas que quelqu'un ici ait dit le contraire. auto est juste un nouvel outil dans cette boîte.

Lorsque l'on fait du "C with classes" (c'est quand même du C++...), on peut faire des programmes simples à lire, sécurisés et performants.

Mais qu'appelles-tu ici du "C with classes" par opposition au "Modern C++" ? Ou dit autrement qu'est ce qui pour toi marque le passage de l'un à l'autre.

Si c'est l'usage intensif de template et de métaprog, je suis d'accord.
Par contre s'il s'agit de l'usage du RAII et de l'exception safety, là je ne suis plus d'accord du tout. Il est compliqué de faire dans cette situation un programme sécurisé et nécessite bien plus d'effort (quant à la lisibilité ! avoir les 3/4 du code simplement pour gérer les cas non nominaux je ne trouve pas que ça aide à la lisibilité).

Ce que je n'aime pas ici, de la part de nombreux intervenants, c'est venir nous expliquer que le C++, c'est le "C++ Modern" et rien d'autre. J'ai les arguments pour expliquer que le "C with classes" à encore sa place...

Même question d'autant où met tu la frontière entre les deux. Et même réponse de ma part.

Le C++ est multi paradigme. On utilise les "template" ou pas, les "auto" ou pas, les hiérarchies" à 10 étages ou pas. On utilise le plus simple selon nos besoins. C'est la force du C++. Son passé est sa force.

Je pense qu'à peu prés tout le monde est d'accord ici sur ce point.


[1] Même si parfois un peu de dynamisme dans le typage est intéressant. Sinon ni boost.variant ni boost.any n'existeraient.

[white_tentacle]

Si le nombre de lettre n'est pas fondamental, alors pourquoi ne pas écrire le type exact de la variable ?

Quelques arguments ont déjà été donnés, je les reprends :
- dans le cas des templates, ça n’est pas toujours possible (disons qu’on pourrait le faire avec decltype, ça devient beaucoup plus verbeux).
- ça améliore la compatibilité source lors des refactoring.

Lorsque l'on développe, on sait où l'on va. Si on utilise une bibliothèque, on connait ses services et sa valeur de retour. Alors auto est-il vraiment indispensable, si ce n'est pour gagner quelques lettres à écrire dans le designer...

auto remplace avantageusement decltype partout où c’est possible. auto améliore la compatibilité source à plein d’endroits où elle est inutilement bridée (typiquement, les itérateurs).

Après, si ton propos, c’est de dire « on peut faire de la merde avec auto et du code vraiment dégueulasse », j’ai envie de te répondre qu’on n’a pas attendu auto pour ça, et que fondamentalement, ça ne change pas grand chose.

Lorsque l'on fait du "C with classes" (c'est quand même du C++...), on peut faire des programmes simples à lire, sécurisés et performants.

Tout dépend ce qu’on entend par « C with classes ». Mais si on met des exceptions et pas de RAII, alors je ne suis pas d’accord. Et si on ne met pas d’exceptions, l’expérience montre que tout un tas de problèmes ne sont pas gérés convenablement.

[nikko34]

Lorsque l'on développe, on sait où l'on va. Si on utilise une bibliothèque, on connait ses services et sa valeur de retour. Alors auto est-il vraiment indispensable, si ce n'est pour gagner quelques lettres à écrire dans le designer...

Quand on développe une librairie on ne sait pas forcément à l'avance qui va l'utiliser.

Et en utilisation, l'exemple classique des containers C++ c'est de pouvoir facilement remplacer une std::list par un std::vector sans modification de code (à part une ligne) parce qu'ils remplissent le même contrat.

[Luc Hermitte]

Cela m'attriste de lire que le C++ serait victime de son passé. Je fais plus du "C with classes" que du "C++ Modern". Et pour cause, le "C with classes" est d'une simplicité étonnante. Il permet de se concentrer sur d'autres choses plus complexes (hors langage). Le multi-casquette du langage C++ est une bonne chose, mais ne venez pas m'expliquer que le C++, c'est uniquement du "C++ Modern". Le C++ c'est plein de chose à adapter selon les cas.

Lorsque l'on fait du "C with classes" (c'est quand même du C++...), on peut faire des programmes simples à lire, sécurisés et performants.

Le C with classes qui est traditionnellement un C++ sans RAII est impossible à rendre robuste.
Le C++ moderne est un C++ où le destructeur sert à nettoyer les ressources. C'est le RAII. Les dernières nouveautés du C++ sont des gadgets intéressants qu'il faut apprendre à utiliser pour ne pas faire n'importe quoi probablement, mais ce n'est pas ça le C++ moderne.

Le C++ moderne, c'est le RAII avant tout -- dans la bouche de beaucoup dont ceux qui ont écrit le billet au sujet duquel nous sommes censés réagir. Et oui, le C with classes, aka C++ historique, doit dégager.