Talk de Scott Meyers à la DConf 2014

Scott Meyers est un expert du langage C++ et auteur des livres à succès Effective C++ et Effective STL. Lors de la DConf 2014, il a donné un talk intitulé « The last thing D needs » où il parle de C++ et fait un quiz avec le public sur les pièges de C++. La vidéo est chaudement recommandée à tous les programmeurs C++ qui veulent tester leur niveau et peut-être apprendre de nouvelles choses (un niveau correct en anglais est cependant recommandé).

La vidéo est disponible à l'adresse suivante http://www.ustream.tv/recorded/47947981.

Intéressant, ya pas mal de trucs contre intuitif en fait en C++, le pire est

Code:

---

1 2 3 4 5 6 7 8

struct Point { int x, y; }; Point p; Point const& cp = p;   decltype(cp.x) // int decltype((cp.x)) // int const&

---

Des parenthèses qui semblent inutiles et qui pourtant changent le type, la syntaxe est mal foutue quand même.

Par contre pour l'exemple sur le this-> qui permet ou non de compiler du code : résolution des symboles lors de la première phase au lieu de la deuxième dans le cas de templates je comprend pas. (Aux alentours de la 26ème minute)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

template <class T> class Base { public: void doBaseWork() { } };   template <class T> class Derived: public Base<T> { public: void doDerivedWork() { doBaseWork(); } };   Derived<int> *di = new Derived<int>;   template <> class Base<float> {}; template <> class Base<int> {}; // erreur Base<int> déjà instanciée   Derived<float> *df = new Derived<float>;   int main() { di->doDerivedWork(); df->doDerivedWork(); // erreur Base<float>::doBaseWork() non trouvé }

---

Je vois pas le problème (et le code compile), pourquoi il ne devrait pas compiler ? (bug de VS2012 ? Exemple sorti de son contexte ?)

La solution serait

Code:

---

1 2 3 4 5 6 7

template <class T> class Derived: public Base<T> { public: void doDerivedWork() { this->doBaseWork(); } }

---

Il compile parce que visual studio ne gère pas les templates en 2 phases...

En gros, il y a pour les templates une première phase, qui a lieu avant de savoir avec quel type on l'instancie. On vérifie que tout le code qui ne dépende pas du paramètre template est correct. Ensuite une seconde phase aura lieu après instanciation.

Code:

---

1 2 3 4 5 6

template <class T> void f(T t) { g(); t.h(); }

---

Si g n'est pas défini, pas la peine d'attendre l'instanciation de la classe pour remonter une erreur. Par contre, il faut attendre de savoir avec quel T c'est instancié pour savoir si h() est un appel légal ou pas.

C'est important parce que les erreurs de la première phase sont des erreurs dans la fonction, alors que les erreurs dans la seconde phase ont des chances d'être des erreurs dans l’utilisation qui es est faite. Donc autant reporter les erreurs à la bonne personne.

Dans le cas présenté, on a la classe de base qui dépend du paramètre template. Donc dans l'absolu, tout pourrait en dépendre, et il n'y aurais alors plus de première phase du tout. Ce n'est pas ce qui a été choisi. Ce qui dépend du paramètre template doit en dépendre explicitement. Quand on fait f(), on considère que f n'est pas dépendant, donc on ne va pas regarder dans la classe de base (qu'on ne connait pas encore), on se contente de regarder dans la classe dérivée et les fonctions libres. Quand on voit this->f(), on sais qu'on va devoir prendre en compte la classe de base, donc on attend.


Sinon, j'ai trouvé le talk rassurant : s'il doit aller chercher des cas aussi tordus, c'est que le langage n'est pas si mal ;) Et je ne suis pas d'accord quand il dit que personne n'a vraiment cherché à harmoniser et simplifier le langage. Toute la syntaxe d'initialisation à base de {} a justement pour but d'avoir des règles plus uniformes. Alors, certes, s'il considère à la fois les anciennes règles et les nouvelles, il a un ensemble forcément plus complexe, mais s'il ne considère que les nouvelle, la situation, même si pas parfaite, est quand même bien mieux qu'avant !

C'est plus clair, merci. ;)

Étonnant que j'en ai jamais entendu parler, ça doit être relativement courant comme erreur.

Hello

Quelques éléments en complément de la réponse de JolyLoïc. Pour que l'exercice soit pertinent, il faut déjà supprimer cette spécialisation:

Code:

---

template <> class Base<float> {};

---

Ensuite, GCC et Clang sortent bien en erreur dans ce cas, et pour fois, c'est le message d'erreur de GCC qui est le plus clair !

Citation:

---

Envoyé par GCC

main.cpp: In member function 'void Derived<T>::doDerivedWork()':
main.cpp:11:18: error: there are no arguments to 'doBaseWork' that depend on a template parameter, so a declaration of 'doBaseWork' must be available [-fpermissive]
main.cpp:11:18: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated)

---

Citation:

---

Envoyé par Clang

main.cpp:11:7: error: use of undeclared identifier 'doBaseWork'
doBaseWork();
^

---

A noter qu'on peut réussir la compilation avec cette syntaxe:

Code:

---

Base<T>::doBaseWork();

---

Mais à déconseiller car cela référence explicitement la classe de base, ce que l'usage de this permet d'éviter.

Pour ma part, je n'avais jamais rencontré cette erreur avant !

Citation:

---

Envoyé par jblecanard

A noter qu'on peut réussir la compilation avec cette syntaxe:

Code:

---

Base<T>::doBaseWork();

---

Mais à déconseiller car cela référence explicitement la classe de base, ce que l'usage de this permet d'éviter.

---

Bah niveau syntaxe c'est plus logique, visuellement on rend le nom dépendant du template, contrairement à

Code:

---

this->doBaseWork();

---

Citation:

---

Envoyé par Iradrille

Bah niveau syntaxe c'est plus logique, visuellement on rend le nom dépendant du template, contrairement à

Code:

---

this->doBaseWork();

---

---

Oui, mais on désactive la virtualité...