Discussion :

[ptyxs]

Salut,
Moi, j'ai du mal à voir l'intérêt des final d'un strict point de vue design. Ca permet des optimisations pour remplacer des appels dynamiques par des appels statiques. Mais à part ça, je vois pas.

J'avais ouvert une discussion l'an dernier (Intérêt du concept de final) mais je n'ai jamais eu de réponses

Dans Effective C++, 3ème édition, Item 7, Scott Meyers, regrette l'absence d'un équivalent du sealed de C# ou du final de Java en C++ de l'époque. Il pense que toute classe dépourvue d'un destructeur virtuel, et n'ayant de ce fait pas vocation à servir de base pour des classes dérivées, gagnerait à être 'sealed' (donc maintenant : 'final'), en particulier l'ensemble des classes de conteneurs de la STL.

[3DArchi]

Salut,

Dans Effective C++, 3ème édition, Item 7, Scott Meyers, regrette l'absence d'un équivalent du sealed de C# ou du final de Java en C++ de l'époque. Il pense que toute classe dépourvue d'un destructeur virtuel, et n'ayant de ce fait pas vocation à servir de base pour des classes dérivées, gagnerait à être 'sealed' (donc maintenant : 'final'), en particulier l'ensemble des classes de conteneurs de la STL.

*** Soit la classe n'a aucune fonction virtuelle : l'héritage publique de cette classe n'a aucun sens puisque le comportement effectif d'une instance sera forcément celui défini par son type statique. En revanche, l'héritage privé peut toujours être intéressant (cf par expl un héritage de boost::noncopyable). A partir de là, effectivement final peut être intéressant s'il n'empêche pas l'héritage privé. Mais ce qui n'est pas le cas il me semble.

*** Soit la classe a des fonctions virtuelles. Ne pas avoir de destructeur virtuel s'il est public est de toute façon une faute (qui génère un warning par expl dans gcc avec la bonne option, ou encore dans les outils d'analyse statique de code). L'héritage fait sens. Et à part dans un objectif d'optimisation, je ne vois pas un design qui devrait dire à un moment que l'héritage public doit être arrêté. Sauf s'il y a eu une entourloupe au contrat de base.

[ptyxs]

Pense à l'exemple, donnée par Scott Meyers, des classes de conteneurs de la STL, qui ne sont pas conçues pour être la base d'une classe dérivée, mais qui - malheureusement - peuvent l'être. Interdire la dérivation dans de tels cas serait probablement une excellente chose.
On peut imaginer d'autres cas de ce genre, j'imagine, des classes qui ne sont absolument pas conçues pour être la base d'une quelconque autre classe, que ce soit par dérivation publique ou privée, non ?
Ton exemple de la classe uncopyable est intéressant et montre simplement qu'on doit procéder là comme ailleurs au cas par cas...

[JolyLoic]

De telles classes ne sont certes pas faites pour de l'utilisation polymorphe dynamique. De là à en empêcher la dérivation, je ne suis pas certain que ce soit une bonne idée.

Imaginons que j'ai un algorithme qui utilise une classe ayant comme concept tout ce que fourni un vector, plus 1 fonction. Je veux grosso-modo passer un vector à cet algorithme, et comme je n'ai pas de concept_map, je vais créer un adapter pour vector.

Comment créer un tel adapter ? L'idéal peut sembler de créer une classe ayant un vector en variable membre privée, qui forward tout à ce vector. Sauf qu'écrire ça demande d'écrire toute une palanquée de fonctions de forwarding, l'interface de vector étant très grande.

Finalement, n'est-ce pas mieux dans ce cas de dériver de vector, et d'ajouter la fonction manquante ? Éventuellement on peut bloquer la création d'instance de cette classe, et documenter qu'elle n'est pas destinée à du polymorphisme dynamique. On a alors nettement moins de code à maintenir.

Ce cas n'est pas forcément courant, suffisamment peu pour qu'en première approximation, on dise : "Les classes de la STL ne sont pas faites pour être dérivées". Mais de là à ce que le compilateur m'empêche de le faire si j'en ai quand même envie...

[Flob90]

@ptyxs: J'ai du mal à voir des cas où on pourrait formellement interdire l'héritage d'une classe. L'héritage privé est une alternative à la composition (relation has-a), outre le fait que ca peut être plus simple à écrire (l'exemple de JolyLoic), il devient indispensable lorsque ce sous-objet doit être initialisé avant un autre sous-objet hérité. Et je ne vois pas comment, d'un point de vue conception, on peut prévoir que ce genre de cas n'arrivera jamais.

[ptyxs]

Bon. Il est vrai qu'on ne trouve guère sur la Toile d'exemple d'emploi concret de cet attribut final, en dehors du cas que j'évoquais et auquel il a été répondu de façon plutôt convaincante...
D'autres idées sur la question ?

[Luc Hermitte]

Imaginons que j'ai un algorithme qui utilise une classe ayant comme concept tout ce que fourni un vector, plus 1 fonction.
[...]

Au détail que nous savons très bien que nous n'aurons jamais accès aux internals du vecteur, et que l'ajout de cette fonction marchera très bien par l'extérieur. (si l'ago est template pour accepter un type vecteur ou autre, on a de bonnes chances que nous puissions le corriger pour émuler la map avec des traits, à l'ancienne -- je ne vois pas beaucoup de libs STLiennes qui sont templates, COTS, et qui supposent des fonctions par rapport aux vectors, d'où mon a priori de développement interne).

Je vois ce que tu veux dire. Je l'ai déjà rencontré plusieurs fois, du moins la mauvaise version (je n'ai encore jamais croisé le cas de vecteur avec une fonction en plus qui est attendue par un algo) et je commence à me dire qu'elle manque de recul.
- Car les détails nous restent interdits, et que l'ajout par l'extérieur et autres traits (certes lourds) marchent très bien
- car nous ne pouvons changer aucun comportement de base (pas de liaison tardive sur les fonctions)
- car pour la même raison, assurer un nouvel invariant est très compliqué à partir du moment où l'héritage est public (ex: container de pointeurs dont on est responsable (-> erase/clear/destr appellent delete), container trié, etc)

[JolyLoic]

L'ajout par l'extérieur pose parfois des problèmes d'ADL, c'est ce qui fait que ça n'a finalement pas été retenu pour le ranged for loop.

Il est même évoqué assez sérieusement pour C++ post 11 d'étendre ce genre de mécanisme (Herb parle d'extention method, à la C#, Bjarne parle de rendre plus ou moins équivalent a.f() et f(a)).

Un autre inconvénient des classes de traits est qu'elles apparaissent dans les messages d'erreur, les rendant encore plus compliqués.

A part ça, je suis globalement d'accord avec toi. Je dis juste que si je tombe sur le cas où ça pourrait marcher, j’aimerais autant que le compilateur ne me bride pas.

[GeantVert13]

Bonjour à tous,

Je me posais une question (qui est peut-être bête) à propos de l'implémentation du multithreading dans le nouveau standard...

D'après ce que j'ai compris, une grande partie de C++2011 sera basée (légitimement je suppose, puisque, apparemment, très efficace) sur boost qui est sous licence libre. En revanche, pour ce qui est des thread, ce sera plutôt basé sur la lib just::thread qui est payante et qui vient de la société justSoftware. Le directeur technique, Anthony Williams, étant l'un des auteurs du nouveau standard, ne trouvez vous pas qu'il y a comme un léger conflit d'intérêt ? Y a-t-il eu de tels cas pour les versions antérieures de C++ ?
Cela posera-t-il des problèmes de copyright (ou de royalties à reverser) pour les éditeurs de compilateurs ?

Merci.

[Flob90]

La norme impose une convention pour manipuler les thread, elle ne propose aucun code (il n'y a que l'interface). Chacun est libre de l'implémenter, et la société que tu cites a décidé de le faire, comme n'importe qui d'autre pourrait le faire et comme vont devoir le faire tout les fourniseurs de compilateurs.

C'est just::thread qui se base (est une implémentation de) sur la norme, pas l'inverse.

De même pour tout ce qui vient de boost, les compilateurs peuvent reprendre le code de boost (je crois, la license est très permissif il me semble), mais ils ne sont pas obligé de le faire. (de plus que les interfaces proposé par boost et par la norme ne sont pas nécessairement identique)

[GeantVert13]

C'est just::thread qui se base (est une implémentation de) sur la norme, pas l'inverse.

C'est justement là qu'est le conflit, Anthony Williams, aurait-il pu "pousser" certains choix pour mieux vendre sa lib ?

Bon c'est sûrement pas très important, c'est juste une question que je me posais...

Si ça ne bloque pas les éditeurs c'est tant mieux.

Merci pour la réponse en tous cas.

[r0d]

Il y a bien évidemment des conflits d'intérêts dans le commité.
Je ne serai même pas étonné que certains membre ne viennent que pour "défendre leur bistec", ou plutôt celui de leur entreprise.
Mais je n'en sais pas beaucoup plus sur ce sujet, je ne m'y aventurerai donc pas plus. En revanche, je serais trés intéressé par l'avis de ceux qui en savent plus sur la question...

[JolyLoic]

Dans le cas des threads, c'est un peu l'inverse qui s'est produit : Anthony est la personne qui a proposé la majeure partie de l'interface des threads dans la norme. C'est par la suite (ou du moins en même temps) qu'il a développé une implémentation de cette bibliothèque qu'il propose maintenant à la vente. Il a donc écrit sa bibliothèque en fonction de ses propositions pour C++0x, et non pas fait du lobbying pour que sa bibliothèque préexistante soit adoptée. Et ce genre de comportement est recommandé : On est ainsi certain que la bibliothèque en question est implémentable, et on peut se faire une idée de la qualité de son interface en grandeur nature avant de voter pour quelque chose que l'on n'a vu que sur papier.

Il ne faut pas oublier que la majorité des participants au comité sont des employés d'entreprises qui doivent avant tout y représenter les intérêts de leur boîte (par exemple, rien qu'en terme de compilateurs, j'ai vu des gens de Microsoft, Sun, gcc, Intel, IBM, EDG, ce qui couvre quand même une grosse part du marché). C'est ainsi que fonctionne un comité de normalisation. La seule contrainte est grosso modo que les informations données par ces membres ne doivent pas être couvertes par un brevet (lire par exemple les liens dans http://www.open-std.org/jtc1/sc22/wg...2011/n3265.pdf).

J'ai en tête certaines personnes dont on pourrait croire que leur principal objectif est que C++0x n'apporte rien par rapport à C++98, histoire qu'ils n'aient pas de nouveaux investissement à faire...

Alors, certainement, les membres sont partiels. L'idée c'est qu'à devoir voir se mettre d'accord suffisamment de gens partiels, on aboutisse à un consensus auquel les entreprises peuvent adhérer (une norme non suivie est inutile), et qui soit finalement un compromis correct.

[Klaim]

J'ai vu beaucoup de fois dans les présentations de Stroustrup le point sur le fait qu'il manque pas mal de représentants des utilisateurs du language. J'imagine qu'il n'y en a aucun en rapport avec le jeu vidéo par exemple?

Je me demandais si des mesures ou des projets pour corriger ça ont été mis en place, ou est-ce qu'il y a des propositions à ce sujet?

[JolyLoic]

C'est assez vrai. On peut même dire qu'un problème est qu'un certain nombre de simples utilisateurs qui y vont s'y font happer par de nouvelles opportunités de carrière.

Finalement, la catégorie la plus représentative des "utilisateurs finaux", par rapport aux développeurs de compilateurs ou de bibliothèques est souvent le monde de l'enseignement.

Pour ce qui est du domaine du jeu vidéo, je ne crois pas y avoir vu de représentants (même si je me souviens d'un papier présenté par une boîte du domaine, mais suivi d'assez peu d'effets).

En utilisateurs style éditeur informatique, on retrouve au comité Adobe, Bloomberg, Google, et certainement d'autres que j'oublie. Mais ce sont souvent des utilisateurs avancés, probablement pas assez représentatifs de la majorité des utilisateurs du langage.

Un des problèmes pour intéresser un utilisateur lambda, c'est à mon avis l'aspect délai. Quelle boîte peut aujourd'hui se permettre de financer une action qui n'aura pour elle des conséquences concrètes que la décennie suivante, dans le meilleur des cas. Je ne sais pas encore vraiment quand j'aurai enfin la possibilité d'utiliser dans ma vie de tous les jours des aspects du C++0x que je connais depuis déjà 5 ans...

[GeantVert13]

En fait j'ai un peu trop tendance à associer le C++ au logiciel libre... c'est une grossière erreur.

[JolyLoic]

Le langage lui même n'est pas lié à une entreprise (contrairement par exemple à Java ou C#). Mais ses implémentations peuvent tout à fait être propriétaires, c'est le cas de la majorité d'entre elles.

[Klaim]

Pour ce qui est du domaine du jeu vidéo, je ne crois pas y avoir vu de représentants (même si je me souviens d'un papier présenté par une boîte du domaine, mais suivi d'assez peu d'effets).

Tu parles de l'EASTL? (dernières news à ce propos)

Un des problèmes pour intéresser un utilisateur lambda, c'est à mon avis l'aspect délai. Quelle boîte peut aujourd'hui se permettre de financer une action qui n'aura pour elle des conséquences concrètes que la décennie suivante, dans le meilleur des cas. Je ne sais pas encore vraiment quand j'aurai enfin la possibilité d'utiliser dans ma vie de tous les jours des aspects du C++0x que je connais depuis déjà 5 ans...

Au delà du délai, j'ai l'impression que quelqu'un intéréssé pour participer devra de toutes manières être financé par son entreprise?
Si je veux être présent aux commités, ne serait-ce qu'en tant qu'observeur, ça coute assez cher non? Hors billet d'avion j'entends.

[JolyLoic]

Tu parles de l'EASTL? (dernières news à ce propos)

Oui, je parlais bien de ça.

Au delà du délai, j'ai l'impression que quelqu'un intéréssé pour participer devra de toutes manières être financé par son entreprise?
Si je veux être présent aux commités, ne serait-ce qu'en tant qu'observeur, ça coute assez cher non? Hors billet d'avion j'entends.

Ça dépend des pays. En pratique, tant que tu ne veux pas le droit de vote, c'est gratuit (hors logistique). Si tu le veux, il faut généralement payer ton comité de normalisation national, et les règles varient (par exemple, en plus d'une somme d'argent, les US imposent une présence aux réunions. En France, on a un arrangement avec l'Afnor, et seul l'un d'entre nous paye pour les autres).

[Klaim]

Et tu te souviens pourquoi l'EASTL avait été peu considérée?

Désolé je diverge un peu mais ça me fascine parcequ'il y a pas mal de choses dans l'EASTL qui peuvent bénéficier a tout le monde et je trouve toujours étrange que les gens très expérimentés disent que le document est un peu naif sans expliquer pourquoi.

Si t'as une idée du pourquoi ça m'interesse.