lmg HS a écrit 174 commentaires

Il me semblait bien que j'avais vu passer des choses en plus de la conf d'Andrei Alexandrescu: une proposition d'évolution pour disposer d'un type std::expected<> est en cours: http://open-std.org/Jtc1/sc22/wg21/docs/papers/2016/p0323r1.pdf

Il est présenté comme une généralisation de std::optional.

(Je doute que ce message ait beaucoup de visibilité vu mon temps de découverte de l'article original, mais voici tout de même quelques remarques).

De la programmation par contrat

Tout d'abord, la Programmation par Contrat est totalement méprise—ou très mal présentée. Son objectif n'est pas de gérer des problèmes plausibles et liés à l'environnement tel qu'un fichier illisible, corrompu, ou encore des sockets plantées.
Son objectif est de traiter les erreurs de programmation. C'est pour cela que l'on dit que c'est à l'utilisateur de vérifier le contrat d'appel (pré-conditions avant d'appeler la fonction). Appeler pop() sur une pile vide est idiot. De même que d'accéder à un élément hors bornes, ou d'exécuter sqrt(sin(x)-1) sur tout x. Ce sont autant d'erreurs dont la prévention est de la responsabilité de l'appelant.

Je n'apprécie pas cette méthode car elle est source de nombreux bugs difficiles à trouver.

A ce sujet, je préfère 100 fois une assertion là pour détecter une précondition non remplie qu'une exception pour analyser ce qu'il se passe. En terme d'investigation, c'est un vrai bonheur à contrario de toutes les alternatives dynamiques (pour repérer et tordre le coup aux erreurs de programmation en C&C++, donc). Je suis d'accord accessoirement sur le fait que les types opaques c'est encore plus mieux. Mais cela complexifie les choses car un strictlypositive<> * strictlynegative<> donne un strictlynegative<>, mais quid de l'addition ? (Ou alors, il faut faire comme avec boost.unit et avoir une arithmétique sur des range<min, max>. Hum… C'est tordu, mais ça peu m'amuser à investiguer.)

Bref, je me suis déjà longuement étendu sur le sujet par ici: http://luchermitte.github.io/blog/2014/05/24/programmation-par-contrat-un-peu-de-theorie/ (série de 3 billets)

Des exceptions dans la SL

Il y a effectivement peu d'endroits où la SL choisit de lancer des std::logic_error, qui sont des exceptions qui signifient "erreur de programmation". En général, une approche pure contrat, mais pas toujours instrumentée est employée. Cf les "STL checkées" sur le sujet. Et j'espère qu'après le C++17 si les évolutions sur les contrats sont validées, toute la SL sera annotée pour spécifier les contrats de toutes les fonctions qui en ont.

De mon avis, std::vector<>::at() est une hérésie qui n'aurait jamais du exister.

Ailleurs, s'il y a des choses qui peuvent vraiment échouer, des exceptions de runtime (dans la terminologie C++, je sais que runtime error veut dire le contraire dans d'autres langages) seront lancées—d'autres exemples ont été donnés. J'ai envie de dire que quelque part, c'est plus nos métiers qui vont vraiment détecter des situations exceptionnelles (et plausibles) et à ne pas confondre avec des erreurs de programmation.

A propos d'optional et des erreurs

Si dans le contexte d'une fonction de recherche, un retour optionnel (qui ne signifie pas forcément "erreur") a du sens, dans le contexte de retour d'erreurs de runtime (au sens C++ donc), optional n'est pas un bon outil car il ne porte en lui aucun contexte. Et tu nous montres ici à quel point les enchainements ne sont pas propres/simples.

Je vous invite plutôt à vous tourner vers des types comme expected. Il y a eu un article sur le sujet en 2012 et de l'encre électronique a coulé (pour encore plus de monadification de la bête) après ça :
- la vidéo de la conf: http://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C
- les slides: https://onedrive.live.com/?cid=F1B8FF18A2AEC5C5&id=F1B8FF18A2AEC5C5%211158&parId=root&o=OneUp

Pour le coup, c'est fait pour. Et c'est plus proche du genre de type que cet article recherche.

A noter un repproche que je fais aux pointeurs intelligents standard: ils ne savent gérer que la mémoire, alors que ce n'est qu'une seule des ressources que l'on peut manipuler (alors qu'un descripteur de fichier UNIX est un int, par exemple)

Justement, le deleter sert à choisir comment on restitue la ressource, et de fait on peut employer les pointeurs intelligent du C++11 (et boostien) sur n'importe quel type de ressources.

auto p = shared_ptr<FILE>(fopen(foo), [](FILE *f){ if (f) fclose(f); });

Cela manque d'un chouilla de surcouche pour une utilisation aisée. Reste que c'est un cas de figure prévu.

Le C++ ne permets pas non plus, à ma connaissance, de vérification sur les under/over-flow d'entier.

On déporte ça à de l'analyse statique, ou aux sanitizers.

Il me donne le choix d'utiliser les exceptions (à condition de se passer de la STL, certes).

Pratiquement tous les algos sont neutres relativement aux exceptions.

Si je comprends bien, avec une lambda vous solutionnez le problème des références pendouillantes que l'on a avec les libs usuelles comme Eigen sur

auto temp = a * x + b;
vect r = temp * 42 + y;

J'avais tenté de résoudre ça avec une approche bien plus tordue.

Il est vrai que certains enchaînements type CTRL + touche non alphanumérique (comme les parenthèses, accolades et compagnie) se perdent, mais ils se résolvent avec quelques mappings de substitution.

Pour le reste, l'azerty ne pose aucun problème, et ce même pour les snobs qui refusent les touches de curseur et ne jurent que par hjkl. L'essentiel des principaux raccourcis sont d'origine mnémotechnique. Peu importe où sont les touches tant qu'on sait où elles se trouvent et comment il faut les prononcer.

Je me suis laissé avoir par le bouton de la zone d'édition.
Merci à vous deux. Je saurais pour la prochaine fois.

En C tu n'auras pas ces choses là:

    enum type { un, deux, MAX__};
    char const* const names[] = {"un", "deux"};
    static_assert(MAX__, std::extend<decltype(names)>::value); // écrit de mémoire

Ni

    enum class type { a, b, c, MAX__};

Ni mon préféré en C++98/03

    struct TypeEnum {
        enum type { un, deux, MAX__};
        TypeEnum & operator++() {
            assert(m_value < MAX__);
            m_value = type(m_value + 1);
        }
        // + constructeurs, fonctions pour convertir, ...
    private:
        type m_value;
    };

Mais je reconnais volontiers que ce n'est pas forcément l'extrait le plus alléchant. Mais bon. On trouvera toujours à redire car au fond, l'Oncle Bob a déjà décrit SOLID en long et large, ou encore le RAII est un classique des FAQs, etc.

Désolé. Avec les proxys je ne pouvais pas vérifier. Il ne me reste que le titre: Donc, une conf d'Alexander Stepanov: "STL and Its Design Principles" (2002)

Je réfute le fonctionnel en production car la logique de pensée n'est pas compatible avec l'immense majorité des développeurs sur le marché. Ce n'est pas "par principe". Loin de là.

Je reconnais volontiers les qualités des langages que tu cites, mais fait voir les réactions quand on commence à suggérer OCaml en place de Python (par exemple).

Parenthèse. Sur les critiques de l'objet, Stepanov avait donné une conférence très intéressante où il parlait, entre autres, du pourquoi la STL (une des grosses parties de la bibliothèque standard du C++) n'est pas OO. (là, à priori: http://video.google.com/videoplay?docid=-7867514878945314586)

Ce type de bouquin est loin de traiter des choses qui sont spécifiques au C++. C'est d'ailleurs le sens que j'avais voulu donner dans la préface : dans les difficultés du C++, il y a celles du génie logiciel, celles du monde OO, celles du métier à traduire, etc. Plus celles spécifiques au C++.

Et ces dernières sont des difficultés essentiellement parce que les développeurs sont restés avec leur idées préconçues d'un C avec classes où la mémoire se gère à la main, et où les erreurs se remontent à la main. C'est sûr que ça ne scale pas et que ce type de programmation ne peut que nous exploser à la figure. Je traduis cela comme un problème de formation. D'où ce type de livre (celui dont on parle, mais aussi les XC++ de Sutter, le C++ Coding Standards de Sutter & Alexandrescu, etc. qui vont tous traiter du RAII).

Et BTW, j'attends toujours de voir le langage maintenable (et donc à la philosophie compréhensible par tout le monde, ce qui tend à exclure les langages fonctionnels qui ne sont pas dans les moeurs), sécurisé, et tout et tout.

google ne donnera rien de bon pour AC++, (M)EC++, (M)XC++, PPPuC++, ou le TC++PL non plus.
Sur les forums spécialisés, les gars qui y trainent sauront décrypter les titres de ces bouquins.

C'est le style Whitesmiths. J'ai un mal de chien avec ce truc sur les projets qui l'exigent. J'oscille entre le style Allman et K&R/Stroustrup quand j'ai le choix.

Plus d'infos là: http://en.wikipedia.org/wiki/Indent_style

Il ne faut pas se leurrer, il y a beaucoup de concepts qui transcendent les langages. Toute la partie OO sur SOLID et Déméter est applicable à tous les langages OO mainstream. Et ce n'est pas parce que c'est indépendant du langage qu'il ne faut pas les traiter!

Après, il ne faut pas s'inquiéter, le livre est définitivement orienté C++. Quand Philippe/koala aborde des principes comme l'ISP, il le fait selon un angle C++.

(Et vous pouvez rajouter toutes les spécificités du C++ en plus: RAII, valeur vs entité, …)

(Encore un Addisson-Wesley … :) )

Dans un genre proche et différent à la fois, tu as le CRTP, ou encore Mixin-Layers façon Smaragdakis (boudiou! plus de 10ans après, je sais toujours l'écrire…)

Pour le MC++D, en fin de compte, ce qui a été retenu dans boost (et par continuité) dans le dernier standard a des approches différentes (pour les smart-pointeurs, les listes de types, …)

Globalement, tous les bouquins de C++ publiés chez Addisson-Wesley sont excellents…

La Forme Canonique Orthodoxe de Coplien précède légèrement la Rule of Big Three. Elle traite également du constructeur par défaut. La version à 3 va supposer un constructeur, mais sans le compter (car il faut bien positionner les invariants)

Quant au passage à 5, il est traité §17. Au moment de l'écriture, on n'avait qu'un seul article sur la règle à 5 ou 0. Et celui que tu pointes (et qui est plus abordable que le premier) n'était pas encore écrit. C'est le genre de chapitre qui pourrait être patché dans les versions électroniques. (Je passe la main à Patricia et/ou Philippe ^^')

Bref. Non, le livre ne s'arrête pas au C++03. Il y a des éléments de C++11 dedans. Mais pas de C++14 dans mes souvenirs.

Et de toutes façons, quand les développeurs, ou plutôt les qualiticiens, respecteront correctement la règle de 4/3, ou mieux de 2 (2 == avec du RAII dedans)—C'est à dire en respectant les sémantiques des classes—on pourra pinailler sur la version 5-0 en C++11.

Cet extrait peut desservir le contenu. Là, ne sont présentées que les syntaxes les plus maladroites. La syntaxe C++11 à préférer est donnée quelques pages plus loin.

Les (M)EC++ sont beaucoup plus techniques. En comparaison, le chapitre OO de Coder Efficacement est plus éloigné du langage, et il sera valable dans tous les langages OO (mainstreams).

Après, c'est sûr que quelqu'un d'assidu aux forums C++ techniques comme clc++m, dvpz, ou le sdzoc, ou qui connait les FAQs par cœur n'apprendra pas grand chose…

Tu perds alors la copy-elision. Cf la présentation donnée par STL lors des Going Native de 2013 -> http://www.developpez.net/forums/d1378055/c-cpp/cpp/going-native-2013-stephan-lavavej-don-t-help-the-compiler/#post7481185

goto est pertinent en C pour collecter les ressources en cas de problèmes.
Pour gérer les ressources, en C++ on part sur le RAII. On n'a plus besoin d'imposer une approche SESE (Single Entry Single Exit) où l'on factorise la collecte des ressources (cas nominaux et cas exceptionnels/erreurs).

A partir du moment où les ressources sont surveillées, et que l'on n'est plus dans du SESE only, libre à nous de remonter des exceptions (préférables car l'impact est nul sur les chemins nominaux avec les compilateurs d'aujourd'hui, et que les erreurs ne peuvent pas être ignorées, et qu'en cas de soucis, les perfs on s'en fout) ou de continuer à remonter les codes d'erreurs à la main (ce qui va impacter les performances vu que l'on va avoir un if toutes les 2-3 lignes pour tester chaque appel de fonction et remonter en cas de soucis—enfin, si on veut écrire un code robuste).

De la lecture sur ces sujets: http://alexandre-laurent.developpez.com/cpp/retour-fonctions-ou-exceptions/

Parenthèse
Le sens exact du cast C dépend du contexte en C++. La simple présence d'un type non défini, mais juste déclaré (dans l'expression) peut aussi changer son sens.
Quant à reinterpret_cast<>, comme son nom l'indique, c'est pour interpréter autrement une séquence d'octets. Je suis d'ailleurs surpris que tu dises que ce soit lui à utiliser sur un dlopen car la norme préconise static_cast<> vers et depuis du void*.

PS: Passer au C++ moderne (RAII, lib standard) limite grandement les risques autour de la mémoire. Il faut juste se débarrasser de sa façon de programmer C, et plutôt se rapprocher de ce que l'Ada nous apprend (vu comme il est compliqué (comme dans, il faut vraiment le faire exprès et le vouloir) d'aller bidouiller la mémoire avec lui—dans mes souvenirs)

[Je ne vois pas trop d'où sort ton post (relativement au précédent, mais bon)]

Concernant la PpC et le fonctionnel. Le C++ intègre quelques outils du fonctionnel avec l'arrivée des lambdas dans le C++11. On peut trouver à redire, mais cela reste mieux rien. La PpC, même si elle n'est pas enrobée de sucrage syntaxique, marche très bien en natif. Le pattern NVI est un bon début (je te laisse chercher dans la FAQ C++ de dvpz, ou sur le More C++ Idioms en wikibook). Il suffit ensuite de choisir entre assertions pour traquer l'erreur de programmation, ou exceptions pour l'erreur de contexte ou la programmation défensive.

Sinon, hormis pour le fonctionnel (et la generative meta-programmation), Eiffel présente(/ait?) beaucoup de ces choses.

Le move n'est pas un swap. C'est comme son nom l'indique : un transfert de contenu et de responsabilité.

Complémentaire ? Où ? Dans les cas d'utilisation initiaux du COW ? C'est à dire /in/ et /out/ de fonction, nullement. Le COW n'était qu'un palliatif à un (N)RVO pas toujours appliqué, à des rvalue-references inexistantes, et à des utilisateurs qui ne veulent pas apprendre à se servir de "const&". Concrètement, les besoins de partage de chaines sont des plus réduits, ou trop simplistes (le COW n'a aucun rapport avec les chaines qui ne sont que des vues à l'intérieur de chaines plus importantes -- il pourrait (presque), mais n'a jamais été utilisé pour cela à ma connaissance -- cf les iterator_range utilisables sur boost.split: http://www.boost.org/doc/libs/1_48_0/doc/html/string_algo/usage.html#id3115768)

Les rvalue-reference vont rendre caduc le besoin technique majeur qui a conduit au COW dans les implémentations de QString et de certaines (pré 2011) de std::string -- par "besoin technique", je n'inclue pas les utilisateurs qui préfèrent s'en tenir à un sous-ensemble du langage très réduit, limite pré-98, et qui préfèrent donc copier en entrée/sortie de fonction.

Le COW sur les chaines et autres classes en C++ est avant toute une optimisation tournée vers les perfs. On pouvait y gagner sur les sorties de fonctions quand le (N)RVO ne s'appliquait pas, ou les stockages dans des conteneurs/tableaux.

Du coup avec l'arrivée de la sémantique de déplacement en C++, le seul intérêt restant est effectivement le partage de mémoire.
Vu le surtout à l'exécution (lock atomique qui n'est pas si gratuit que cela -> http://www.gotw.ca/gotw/045.htm), je doute que le COW soit maintenu à termes dans Qt (quoiqu'ils n'ont toujours pas ni namespace ni exceptions ...). D'ailleurs, si la chaine standard du C++11 a été rendue incompatible avec le COW, c'est bien tout sauf involontaire: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2668.htm

Le problème est que le partage de chaine serait le bienvenu sur les chaines immuables. Avec le COW, on a une sorte de tout-terrain qui certes passe partout, mais qui consomme plus.

La partie Vundle/Bundle, c'est un peu comme le CPAN.

Seul bémol cela ne gère pas les dépendances -- du moins la dernière fois que j'ai vérifié. À contrario de vim-addon-manager de Marc Weber.

PS: les deux omapping auraient dû être définis locaux au buffers (la)tex.