lmg HS a écrit 174 commentaires

Dans le genre, après l'allocation unique, je serai parti sur std::ifstream::read() aussi. Histoire de comparer des choses similaires…

Tu peux t'installer les dev-tools (?) de red-hat pour avoir un gcc plus récent pour commencer. Cela permettra ensuite de compiler clang.

J'ai cette "vieille" procédure que je mets à jour tous les 4 matins car il y a régulièrement des petits changements: https://github.com/LucHermitte/install-clang
Ma dernière utilisation en date, c'était pour du ubuntu 18, clang 13.0.1, et il y a un petit hic qui fait que tout n'est pas automatisé. J'avais du reprendre la main et relancer en cours de route :(

NB: j'ai aussi fait le choix que clang soit compilé par lui-même avec dépendance à libc++ dans la dernière itération. Et que la lib standard par défaut soit libc++ (et non stdlibc++ du système). C'est parfois un peu casse-pieds dans un monde linux sur des gros projets avec plein de dépendances dans tous les sens et des procédures de compilation très hétérogènes.

PS: Après je me suis installé lmod (que j'ai découvert après un passage dans le monde du HPC) pour switcher rapidement entre diverses versions de compilateurs.

Si tu regardes les sorties d'asan dans ma réponse en dessous, tu verras que cela ne pointe pas au même endroit entre l'asan de clang et celui du système/gcc.

J'ai d'ailleurs une nette préférence à avoir l'asan de clang++ que je me compile régulièrement. Il est ainsi un chouilla plus à jour, mais aussi il se perd moins souvent pour retrouver ce qui est fait à telle ou telle ligne.

s/qui ne seront jamais vus AVEC tableaux/qui ne seront jamais vus AVANT tableaux/

C'est pénible de ne pas pouvoir éditer nos réponses…

Je débarque après la bataille… je traîne plutôt sur les forums en ligne (d'OC/ZdS), ou la réponse qui suit t'aurait été donnée.

Un contenu des plus modernisé que l'on trouvera sur l'enseignement du C++ est le big tuto de Zeste de Savoir, et son adaptation en livre. Le livre apporte son lot de corrections et améliorations (sur la partie OO en particulier), et un chapitre entièrement réécrit (gestion des ressources et de la mémoire).

C'est du C++ moderne au sens premier, de 2002 et avant (non, je n'ai inversé aucun chiffres). C'est à dire, que les bonnes pratiques sont mises en avant, que la mémoire est gérée de façon transparente et … correcte. Il existe d'autres ouvrages (dont l'auteur a été cité (*)) où les derniers éléments du langage sont présentés comme des annexes tout en suivant où approche historique de l'enseignement du C++—imaginez un cours de cuisine qui commence par nous apprendre à tailler nos silex pour aller chasser le mammouth.

Le tuto de ZdS est donc moderne au sens premier, mais aussi au sens contemporain où la norme choisie est celle du C++17 pour l'intégralité du cours: les éléments des précédentes normes qui n'ont aucun intérêt pratique pour le débutant ou la pratique professionnelle quotidienne sont passés sous silence, ou traités très rapidement sans insister dessus. Par contre, c'est un ouvrage pour débutants. Il reprend absolument tout. Mais correctement, si je puis dire. Il a été intensivement lu et relu et critiqué par des spécialistes du langage, dont certains enseignent parfois—j'en fais parti, et suis donc parti pris.

Quelques indices pour reconnaitre un bon ouvrage:
- les premiers tableaux enseignés sont std::array et std::vector
- les chaînes de caractères des std::string
- la gestion de la mémoire à la main est vue bien, mais vraiment bien après—cela concerne aussi les pointeurs, qui ne seront jamais vus avec tableaux et chaines.
- dans la foulée de la gestion de la mémoire, voire avant, les pointeurs intelligents type std::unique_ptr<> seront abordés.
- la familiarisation à la bibliothèque standard n'est pas reléguée en annexes/fin de la formation/livre
- l'héritage n'est pas relégué à la factorisation de données, mais au contraire mis en avant pour la factorisation de comportements
- et avec un peu de chances (une préoccupation très francophone), valeurs et entités seront traitées séparément car cela a des impacts sur les recettes de cuisines à appliquer. Comprendre que l'enseignement du C++ ne peut pas se résumer à "voici la syntaxe, débrouillez-vous!". Il est plus important d'associer les éléments de syntaxes aux besoins auxquels on cherche à répondre.

(*) A noter que je suis mauvaise langue, je n'ai pas eu sa toute dernière édition entre les mains pour juger si l'enseignement du C++ avait enfin (!) été modernisé et centré sur les objectifs au lieu de la syntaxe.

Zut. Je n'ai pas réussi à éditer ma réponse.

Je n'ai rien dit. Je n'avais pas fais attention qu'il y avait un second tableau pour la configuration avec un environnement plus récent.

Ceci dit, je me suis déjà compilé des versions récentes de clang++ pour CentOS. C'est fort pratique pour avoir des outils tels que les sanitizers, de meilleurs warnings, clang-tidy, un serveur LSP, etc même quand on est restreints à du C++ 98.

Etant assez surpris des résultats de asan pour certains tests comme alloc-missing-delete, je l'ai relancé sur mon ubuntu 18 avec g++7.5 et un clang++ 13 (compilé main), avec $CXXFLAGS='-fsanitize=address -g -fno-omit-frame-pointer'. Les deux voient la fuite de mémoire

# avec g++
=================================================================
==301==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x7f54ad2ff448 in operator new(unsigned long) (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xe0448)
    #1 0x5576a8634852 in main /home/moi/dev/tests/c++/alloc-missing-delete.cpp:3
    #2 0x7f54ace4fc86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).

# avec clang++
=================================================================
==1267==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
    #0 0x4c8c5d in operator new(unsigned long) /home/moi/local/clang/src/llvm/compiler-rt/lib/asan/asan_new_delete.cpp:99:3
    #1 0x4cb57f in main /home/moi/dev/tests/c++/alloc-missing-delete.cpp:3:18
    #2 0x7f5ff312cc86 in __libc_start_main /build/glibc-uZu3wS/glibc-2.27/csu/../csu/libc-start.c:310

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).

Au passage, clang-tidy voit la fuite aussi:

2 warnings generated.
/home/moi/dev/tests/c++/alloc-missing-delete.cpp:3:10: warning: Value stored to 'value' during its initialization is never read [clang-analyzer-deadcode.DeadStores]
    int* value = new int(argc);
         ^
/home/moi/dev/tests/c++/alloc-missing-delete.cpp:3:10: note: Value stored to 'value' during its initialization is never read
/home/moi/dev/tests/c++/alloc-missing-delete.cpp:7:5: warning: Potential leak of memory pointed to by 'value' [clang-analyzer-cplusplus.NewDeleteLeaks]
    return 0;
    ^
/home/moi/dev/tests/c++/alloc-missing-delete.cpp:3:18: note: Memory is allocated
    int* value = new int(argc);
                 ^
/home/moi/dev/tests/c++/alloc-missing-delete.cpp:7:5: note: Potential leak of memory pointed to by 'value'
    return 0;
    ^

J'ai le souvenir inverse: que msan et asan ne sont pas compatibles, alors que asan est compatible avec ubsan—et pour le coup, aucune raison de ne pas les combiner: on peut plus sereinement faire tourner les tests en -O2 -g.

La préconisation d'[Herb Sutter] est d’élargir au maximum l’interface des classes par l’extérieur et de garder membres uniquement les fonctions qui ont besoin d’aller taper dans les membres privés, ou qui peuvent être supplantées par redéfinition (overridding en VO).

C'est typiquement pas le cas des méthodes size() et data() (pour empty() on peut l'implémenter à partir de size() si la complexité de cette dernière est constante).

C'est vrai, et c'est là que j'aime bien le commentaire d'Alexander Stepanov qui dit que size() aurait dû être une fonction externe et amie.

---

D'un point de vue de la syntaxe, c'est un peu plus compliqué que cela. Dire que a.f(b), b.f(a) et f(a, b) n'est qu'une convention, c'est aller un peu vite… Écrire myValue.addTo(myArray) choque tout le monde quelque soit le langage.

Presque. Je dis que a.f(b), f(a, b), ou (f a b) ce n'est qu'une convention d'écriture. Un sucre syntaxique.
Quand je parle de la validité de a.f(b) ou de b.f(a) c'est dans un contexte de dispatch multiple. L'écriture o.f() est intéressante dans nos langages pour dispatcher l'appel à la bonne fonction f() en fonction du type dynamique exact de l'objet o. Mais quand le dispatch dépend du type dynamique de plusieurs objets, pourquoi en choisir un plutôt qu'un autre? On aura parfois, souvent ?, un verbe qui rend un appel plus clair, mais pas toujours. Un exemple type de dispatch multiple : la gestion de collision entre plusieurs objets de natures différentes (vaisseau, missile, astéroïde…). Dans la collision il n'y a pas un objet qui soit plus acteur qu'un autre.

---

D'un point de vu pratique il n'est pas pratique d'avoir de l'autocomplétion sur des méthodes libres.

Il est vrai que la complétion sur des fonctions libres peut s'avérer moins pratique car le lexique des fonctions libres et plus conséquent—même en restreignant le périmètre à toutes les fonctions pouvant matcher des variables dans la portée courante. Si mes souvenirs sont bons, ce point était ressorti lors des échanges autour de l'UCS. Mais il n'avait pas été considéré comme
critique.

---

D'un point de vu lecture, le chainage est plus compliqué de mon point de vu :

Le chainage o.f().g() respire la vilaine violation de la Loi de Déméter j'ai envie de dire. Quitte à enchainer des transformations de données, je préfère ce qui est fait dans les ranges v3: o | f() | g().

---

Je ne suis pas sûr de te suivre concernant ta remarque sur le structural binding. Les concepts ça reste du polymorphisme statique. Dans le cas du dispatch multiple OO, nous sommes sur du polymorphisme dynamique.

Oui, tout à fait, merci. Je me fais avoir à chaque fois.

Je suis un complet newbs avec l'interface d'édition des articles sur linuxfr et j'avoue ne pas savoir comment procéder pour corriger cela facilement. ^'

Merci :)

Désolé, il y a eu un échec, la dépêche n'était pas prête pour publication. S'il y a moyen de la remettre en édition histoire que je revienne sur un état antérieur publiable, je suis preneur. Merci.

(Quelle horreurs ces fautes, et je ne peux plus éditer mon message :-( )

Je trouve la configuration de YCM complexe et pas aussi souple que ce que j'aimerai. Typiquement, je bosse sur plusieurs projets en parallèle (produit final + dépendances), et en plus pour chaque projet, je peux choisir le mode (un répertoire en fait) de compilation. Or, avec YCM, c'est l'enfer pour lui dire comment trouver intelligemment, et de façon assez dynamique, où trouver la base de compilation JSON (générée par CMake). Plus des plantages lors de mes dernières utilisations. Ce qui fait qu'au final je suis resté sur ma faim. :(

Après, je sais plus si YCM souffre des mêmes problèmes que les autres outils passant par libclang -> il faut rajouter des chemins que clang connait (!) pour trouver ses propres fichiers d'en-tête…

Peut-être parce qu'au delà que c'est un compilateur, clang permet développer quantité d'outils qui vont pouvoir nous assister dans nos tâches quotidiennes, même si la compilation est réalisée avec un compilateur dédié pour ne pas dire exotique parfois.

Les sanitizers ont été cité. Depuis je n'utilise pratiquement plus valgrind. J'ai plus d'informations et plus vite pour les corruptions du tas. J'ai aussi tous les comportements non définis détectés (à l'exécution). Il y a des furieux qui en train d'écrire un efficiency-sanitizer.

Côté analyse-statique de code, il y a des trucs classiques via clang-analyse et clang-tidy. Mais aussi un détecteur statique d'inter-blocages et de courses aux données (moyennant annotations). Quantité d'autres outils d'analyse de code source: OCLint, CppDepend… J'ai même croisé une outil de vérification des règles MISRA C et C++—qui donc à l'a différence d'outils tels que Understand a partage son noyau d'analyse des sources, avec un compilateur C++. Ce n'est pas anodin.

J'ai aussi croisé des outils d'indexation de code ou de refactoring basés sur clang. Plus qu'un IDE a repris ses solutions internes pour travailler sur des codes C et C++ pour des solutions basées sur clang.

Dans les trucs peu conventionnels, on peut aussi citer Cling, une refonte de Clint (si j'ai bien suivi), qui permet d'interpréter du C++.

Encore plus tordu, il y templight, un A C++ Template Metaprogram Debugger and Profiler comme ils disent.

Bref. Clang a initié une révolution dans l'outillage disponible pour travailler en C++. Et il a enrichit le catalogue d'outils pour le C. Et de fait je comprends qu'il soit cité en outillage, chose qui va bien au delà de "un petit compilateur dédié ou restreint à des cas spécifiques". Ce qui me rappelle un machin qui ne sert à rien: un compilateur C écrit (ou plutôt traduit) dans le langage de script de Vim https://github.com/rhysd/8cc.vim. Dans la série, en plus utile, c'est à clang/LLVM que l'on doit les compilateurs C/C++ -> javascripts.

A noter que exhuberant ctags (celui qui est dispo dans des paquets) n'a plus donné des signes de vie depuis des années. Il n'a jamais été très bon pour le C++ d'ailleurs, mais toujours mieux que cscope.

Heureusement, il y a été forké en universal-ctags, qui lui est maintenu. Il a fait des progrès notables côté C++. Il ne saura pas résoudre pour autant les surcharges automatiquement lorsque l'on voudra l'utiliser pour naviguer vers le lieux où un symbole est défini depuis des outils légers tels que Vim.

Pour ça, il faudra regarder du côté de clang. Il y a plusieurs outils d'indexation et j'avoue ne pas avoir suivi leur état de l'art ces derniers temps pour voir celui qui comprenait le mieux le C++ (toutes versions confondues) tout en n'étant pas trop compliqué à paramétrer.

cppunit n'a jamais été très bon. Déjà il y a 20 ans, cxxtest(.sf.Net) avait compris le principe de Don't Repeat Yourself (DRY pour les intimes). Ces dernières années ont été dominées par boost.test et google.test. Et nous avons catch en challenger pas mal du tout.

A noter qu'ils s'intègrent tous très facilement dans CTest et son (C)Dashboard associé.

Sauf dans i-- > t[i]. On ne sait pas qui sera évalué en premier: i-- ou t[i].

Sinon, oui, le principe de la post-décrémentation, c'est de mettre de côté la valeur qui sera utilisée pour la suite et après de décrémenter la variable.

Je serai un peu plus violent encore: grep delete et grep free et je les dégage tous pour suivre une approche 100% RAII—le seul endroit où je m'autorise un tel artéfact, c'est dans un destructeur, et il doit y être seul. Aussi, d'après ce que j'ai lu dans les commentaires d'une autre dépêche, vous allez devoir rajouter des petits : private boost::noncopyable (ou équivalent) à toutes les classes de base et à d'autres entités—ceci dit transformer les attributs pointeur en std::unique_ptr aura pratiquement le même effet: détecter les copies qui n'auraient jamais du être permises. Cf FAQ C++ de dvpz au sujet des sémantiques d'entité et de valeur.

PS: Il existe clang-tidy, clang-analyser, et OCLint en analyseurs FOSS de codes sources. C'est la gamme de produit largement au dessus de ceux qui ont été cités.

Quel est le problème avec les constructeurs de copie ? Qu'il faut savoir quand il faut les définir et quand il faut les interdire ? Ce n'est franchement pas très compliqué.

C'est avant tout un problème de design : savoir distinguer les entités des valeurs, problème qui se pose aussi avec d'autres langages sous d'autres formes: ainsi, cf. les values objects qui ne doivent pas être dérivés en Java (p.ex. un point coloré n'est pas un point, mais il est composé d'un point—cf Effective Java v2).

Certes en C++, un mauvais design va résulter en un plantage plus vite qu'avec d'autres langages qui vont juste se contenter de nous laisser écrire du code susceptible de produire des résultats aberrants.

emplace ajoute l'élément qu'il va construire à la volée avec les arguments donnés.

Je dirais même: directement dans la destination (déjà allouée). Comme le nom l'indique, cela fait de la construction placée avec le new de placement. Mais bon. C'est du détail arcanique. Il est plus important de comprendre dans un premier temps comment on écrit des classes valeurs et savoir distinguer les entités (celles qui n'ont pas besoin d'/ne doivent pas être copiées)—David illustre un cas où le problème peut se poser, celui que tu observes.

Si ta classe possède des ressources, il est nécessaire de prévoir comment tu la dupliques. Si tu autorises alors il faut définir le constructeur de copie et l'opérateur d'affectation par copie (plus éventuellement les équivalents en déplacement si tu veux en profiter), sinon, tu interdis. Comment? Réponse dans la FAQ: http://cpp.developpez.com/faq/cpp/?page=Semantique-de-copie

Dans tous les cas, il te faut un accès au code de ces classes pour spécifier comment la copie et le déplacement se font (ou pas).

En ce moment ils ont commencé une série de dépêches présentant les évolutions du C++17. Je me suis joint à la troupe pour les quelques sujets que j'avais suivis.

Ce à quoi tu fais référence a le vent en poupe en ce moment, en particulier suite aux CppCoreGuidelines et à la bibliothèque support GSL. Il a eu de nouvelles tentatives pour faire standardiser des moyens simplifiés pour définir des types opaques en C++. Il y a eu bottage en touche pour le C++17 avec comme argument, utilisez des enum class. Je suis justement en train d'expérimenter sur le sujet, et j'ai une question d'équilibre à trouver (pour définir des positions et des distances pixelliques dans des images: faut-il vraiment deux types ? signed ou unsigned ? …)

Je m'étais aussi posé la question de définir des types domaines de définition sur des plages réelles, avec objectif à termes de rajouter un chapitre à ma série de billets sur la Programmation par Contrat. J'ai donné le lien il y a deux commentaires de cela—qui pointe vers une autre lib pour avoir des types opaques (ou strong typedef suivant le microcosme d'où l'auteur vient). Je ne suis pas sûr que cela soit vraiment exploitable: il y a un problème de syntaxe, mais aussi un problème de précision de calculs. Il est bien beau de dire que sqrt(1+sin(x)) est toujours défini, mais en pratique 1+sin(x) pourrait être négatif car nous sommes nuls à un epsilon près.

Dans un gist, j'ai une autre expérience avec des types opaques (sans utiliser des enum class), mais la lib publiée sur reddit est bien plus aboutie.

EDIT: Pour les libs, il y en a des tonnes. Eigen, mais aussi blaze pour le calcul matriciel avec un syntaxe humaine. HPX qui fait de plus en plus parler de lui pour l'HPC dans le style du standard de 2011—je soupçonne que les évolutions sur la parallélisation en C++2017 viennent de ce projet. Bref. En général, c'est plus dans les communautés dédiées que je vois passer ce genre de sujets : dvpz, zds, voire sdz/oc. La complétion intelligente dépend de l'EDI. La mode est à encapsuler clang aujourd'hui. Cf p.ex. YouCompleteMe pour vim.

Le langage n'a pas tant changé que cela de ce côté là. Le SunCC 5 et des bananes que j'utilisais il y a une douzaine d'année (et il était encore plus vieux que ça) m'avait surpris en sachant appliquer du NRVO sur des std::vector.

Après, les compilateurs… oui, il y a eu de sacrés progrès (ou investissement de ressources humaines et comptables pour certains) de leur côté.

Tu peux rajouter Eric Niebler (cf commentaires) à la liste des personnes notables qui préfèrent les signés.

Pour ma part je suis toujours un peu dubitatif faute d'avoir pris le temps d'explorer toutes les possibilités et désireux d'avoir une garantie de positivité, mais je sens que nous sommes dans un débat du même acabit que NULL VS 0: le machin sémantiquement fort est un gros piège. En ce moment, je suis plus dans le trip de vouloir savoir si de bosser avec des types opaques du niveau domaine de définition va apporter quelque chose en termes de sécurité: https://openclassrooms.com/forum/sujet/types-opaques-domaines-de-definitions?page=1

BTW, je me trompe ou ton exemple marcherait avec:

for (std::size_t k = 1; k < point.size(); ++k) {
    draw_line(point[k-1], point[k]);
}

Je n'achète pas non plus l'exemple précis du "find_last index qui vérifie v[k] == 0"—sur le github. Probablement parce que ce n'est pas un problème que j'ai fréquemment à résoudre. J'ai rarement besoin de boucler à l'envers.