Discussion :

[Kaamui]

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

[Jean-Marc.Bourguet]

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.

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.

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

[koala01]

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 :

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

1
2
3
4
5
6
class MaClass
{
    public:
        MaClass(auto const & rhs);
        auto operator = (auto const & rhs);
};

est a priori valide

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

[Klaim]

koala01>


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

Code :

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

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

au lieu de

Code :

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

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.

[Kaamui]

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

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 ?

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

[JolyLoic]

Code :

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

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 ?