freem a écrit 4965 commentaires

Ben déjà c'est vrai que ça fait chaud au coeur :)

Ce n'étais pas le but.
Je disais juste la vérité.
Maintenant, si ça vous réchauffe le cœur tant mieux. Mais n'oublie pas: j'ai pas dis: c'est vous qui m'avez convertit, juste que vous avez été un outil qui a contribué à me rendre contributeur à divers logiciels libres, connus ou non.
J'aime pas flatter.
J'encourage pas, non plus, ou pas volontairement, je ne fait que citer le fait que j'ai une meilleure maîtrise de mon système, maîtrise à laquelle vous avez participé en me faisant découvrir des logiciels portables (windows/linux).
Libre à vous d'en tirer fierté, je ne vous en voudrai pas: vous avez été contributeurs. D'ailleurs, vous avez pas précisé la licence :D

La réalité, c'est juste que le temps manque […]

J'imagine.
Vraiment, je conçois très bien.
À priori, c'est assez général, dans le monde associatif. J'y reviendrai.

Maintenant, faut pas hésiter à fouiller […] Pour moi, il n'y a pas d'arguments clés en main, c'est plutôt de chercher à comprendre la dynamique des GAFAM.

Si le problème, c'était moi, quelqu'un qui essaie d'être curieux et d'avoir l'esprit indépendant, alors le problème ne se serait probablement pas posé autant, les argumentaires existant conjugués à ma propre réflexion m'ayant déjà persuadé ou convaincu, en fonction.

Après, ben, c'est du libre associatif, alors si tu as des idées (et envie de les mettre en oeuvre), pourquoi ne pas construire ces argumentaires ensemble ? :)

Je ne suis pas fondamentalement contre, en soit.
Mais, je ne suis qu'un sympathisant et il est peu probable que je m'engage à quoique ce soit. Malgré ça, je suis capable d'argumenter.

Pour moi, si l'on veut que le libre se répande, voire, soyons fous, que l'inter-opérabilité avec des standards ouverts soit obligatoire dans les organes publics (ce qui «encouragera» le privé et donc le public à suivre) il faut d'abord convaincre les organes publics.
Je ne crois pas que le but de framasoft soit de viser les organes publics. Je pense que votre objectif est de convaincre les particuliers en 1er. Je pense donc que c'est la mauvaise façon d'aborder le problème (bien qu'elle m'ait aidé, mais j'y serai probablement venu malgré tout: je connaissais l'existence de linux avant de vous connaître, ce que vous m'avez apporté, ce sont des logiciels libres sous windows, surtout).

En admettant que j'aie raison (ce qui est plus que discutable), un medium efficace serait de filer un coup de main aux associations qui défendent les techniciens et ingénieurs territoriaux, afin de «mettre un pied dans la porte». Elles sont comme vous: elles manquent de main d'œuvre. Et j'ai le «sentiment» que ça vaut aussi pour leur usage d'internet, alors que c'est le domaine que vous maîtrisez le mieux, justement.
Quand je vois le site de l'ATTF (attention, une autre assoce, l'AITF est née d'une scission, je ne connais pas les détails, mais il semblerait qu'il existe une certaine rivalité) par exemple, je comprend pourquoi ils m'ont dis qu'ils avaient des problèmes de com'. Leur filer un coup de main pour moderniser librement leurs infra, permettrait de vous faire éventuellement connaître. À partir de là, qu'est-ce qui vous empêcherait de présenter des outils libres (MAIS répondant à des problématiques réelles) pendants leurs congrès nationaux (mon père est directeur des services techniques d'une ville, et il est clairement non informé aux problématiques de l'informations, de son propre aveu)? Parce qu'a celui auquel j'ai assisté, j'ai eu le sentiment très fort qu'ils avaient du mal à trouver des intervenants.
En «sensibilisant» les professionnels, notamment le fonctionnariat (le libre n'a pas pour seul intérêt la liberté théorique, mais pourrait facilement se conjuguer aux offres de marché publiques, à la notion de ne pas être totalement hors-contrôle…), il n'est pas impossible que vous puissiez influencer les maires. De là, il est possible de répandre les valeurs de l'ouverture au niveau de communes, voire de groupements de communes (je me rappelle pas le nom, me semble que ça change selon le coin en plus).

Mais, encore une fois, je ne suis qu'un sympathisant, je contribue parfois par le code, plus rarement j'essaie de faire changer les opinions, et ça s'arrête là.
Parce que je ne pense pas pouvoir faire plus. Parce que je ne sais pas comment mieux convaincre, notamment.
Vous voulez m'aider à vous défendre sans que ça me coûte un rond? (parce que, soyons honnêtes, j'ai le sentiment que tant qu'il y aura des gens qui savent coder, on pourra utiliser notre PC librement. Ce qui est faux, mais les sentiments sont durs à vaincre.)
Alors expliquez-moi comment convaincre mon entourage. Je suis déjà acquis à la cause (quoique je sois plus BSD que GPL), mais c'est pas mal à cause d'idéaux et de rêves, rien qui ne puisse convaincre une organisation, les décideurs et ceux qui ont le pognon, et c'est bien ça, le nerfs de la guerre: le pognon.

La stabilité, y'a que ça de vrai !

D'où mon amour pour Debian :p

Disons que c'est un signe d'amélioration. Ils sont passé des nightly builds officielles aux versions stables, et ont mis un peu de sucre marketing dessus. Ça reste un mouvent à encourager, pour moi, parce qu'ainsi ils pourront peut-être revenir un peu, ce qui amènera un peu de concurrence au mainstream.

moins que les deux cité et encore c'est pas sur. Par contre ce qui est sur c'est qu'en France, la distribution ne bénéficie pas du même engouement.

Du coup, ça m'intrigue.
Suse, je connais de nom, comme tout le monde, mais quelle est la différence par rapport à Debian? Je me pose la même question pour RHL… enfin, la Fedora avec support… peu importe ça, je suis débrouillard.

En fait, le sujet est trollesque, mais ma question est réelle: existe-t-il un endroit ou il soit possible de comparer les distro en fonction de leurs points forts & faibles, de manière relativement objective?*

Genre, j'aime Debian parce qu'on a la garantie d'une stabilité. Mais d'un autre côté, les paquets sont universels donc peu optimaux voire avec des dépendances débiles (non-technique, parce que l'empaqueteur sait mieux que l'user), alors laquelle prendre pour avoir stabilité et "spécificité" desktop, Par exemple? Et surtout, ou se renseigner?

debian préfère gnome et kde est un laissé pour compte et c'est tout!

Tu me croiras si tu veux, mais je n'utilise pas de DE. Je n'utilise qu'un WM. Pourquoi je parle ici du coup?
Parce que, a l'époque ou je regardais les DE en venant de windows, KDE me plaisait.
Puis parce que, quelques années après après avoir adopté Debian j'ai voulu aider sur la ml. Et ce que j'ai pu lire, a gauche et a droite, c'est que les debianneux s'en tamponnent des DE. Enfin, quand je dis "s'en tamponnent"… je veux juste dire que Debian intègre juste les patchs pour que ça marche techniquement, sans changer les fonctionnalités, l'esthétique n'étant pas la priorité.
C'est très dur à faire, et j'ai vu plusieurs appels à l'aide pour KDE, truc qui va trop vite, et donc dépassait par sa vivacité la capacité de maintenance de Debian en terme de bugfix.
Un bug dans une application? Que l'appli soit Gtk ou Qt, il sera traité de la même manière. En fonction du nombre de contributeurs, et ce nombre est fonction du nombre d'utilisateurs. Si ça bug trop, y'aura moins d'utilisateurs et donc, moins de contributeurs, parce qu'on cherche d'abord une alternative qui juste marche: c'est ça, être un dev, et/ou être une feignasse.

Cela dis, Debian à un gros handicap pour les DEs: Debian est une distribution stable. C'est à dire qu'ils n'intègrent dans la version stable que les correctifs de bugs.
Donc, plus un bureau majeur avance vite et oublie ses anciennes versions, moins il aura de bugfix pour Debian. Moins il y a bugfix pour Debian, distrib majeure, plus il y a bug, moins le DE est utilisable par Debian et potentiellement pour ses filles, et moins il a d'utilisateurs.
C'est pour ça que je pense que la «LTS» (18 mois? C'est bien, mais c'est ce que j'appelle une stable normale moi… mais c'est mieux que rien, au pire m'en cogne) de KDE est une bonne chose.
Le fait que la LTS de KDE soit de 1 an et demi rendra les choses gérables pour les mainteneurs KDE de Debian, qui ne font pas juste de l'empaquetage. Si je voulais troller… ah, j'ai le droit, on est dredi tôt me matin…

Donc, ouai, si les dev de KDE avaient fait la maintenance, les empaqueteurs de debian en auraient moins chié, seraient probablement plus nombreux, y'aurait eu moins de problèmes utilisateurs de transitions, et peut-être même que KDE aurait gagné lors du dernier débat (m'a semblé lire que gnome devenais quand même vachement gros pour tenir sur un ISO avant qu'on arrive sur Jessie…).
Voila pourquoi j'accueille avec une grande joie le fait que KDE annonce une… hum.. LT… stable. Je n'utilise pas KDE, ni gnome, ni… juste un WM et bla bla. Mais pour moi, le fait d'être maintenable est une qualité, que KDE semblait ne pas avoir. L'acquérir lui permettra peut-être d'ouvrir la voie à une saine émulation, qui améliorera peut-être en cascade mes outils.
Voila pourquoi c'est une bonne chose, pour moi qui n'est pas (encore?) utilisateur de KDE.

Les outils de conf de debian sont en gtk et le bureau par defaut c'est Gnome. Oui tu peux le changer mais le defaut c'est Gnome.

S'il te plaît, pourrais-tu citer des noms? Parce que j'ai l'impression de rater des outils utiles la, du coup :/

Il semblerait que ce ne sera possible que l'an prochain, alors que la critique est faite cette année.

Ça, c'était pour la mauvaise foi de circonstance :)
Je reconnaît que je ne connaissais pas le futur std::string_view (et je te remercie au passage de m'informer de son existence) mais je citais un cas présent, avec le standard existant.

Toujours est-il que cette nouvelle classe semble méchamment plus intéressante que std::string, il faudra que je regarde de plus près, afin de questionner les choses que je ne comprends pas, pour évoluer au prix de quelques moinssages. Mais tel est le prix de la liberté :)

Donc, mélanger les compilateurs, même si on fait du C ou du "struct&pointers", c'est dangereux.

YOLO… triste, mais… comment dire… tellement vrai.

À l'heure actuelle, il me semble que ce qu'il se fait c'est du travail sur les conventions C (cdecl & co) et ça permets d'avoir des plug-ins qui marchent à peu près. C'est pour ça que la compat C est si importante: c'est elle qui nous permets de causer, c'est notre lien, c'est la langue indoeuropéene des langages informatique.
De là même façon qu'en électronique, il me semble me souvenir que par convention, l'intensité est inversée par rapport aux fait.
Il serait difficile d'imposer un standard par arch de toute façon, parce que qu'il existe plusieurs OS avec des historiques variés (windows NT, *BSD, linux, solaris, whatever).
Maintenant certains constructeurs le font, c'est une bonne chose pour l'interop. Mon avis, c'est que les gouvernements devraient obliger par la loi l'interop, avec des formats standards en fonction du matos (et être compétents, ainsi que mettre force de loi à des standards entre composants histoire qu'on cesse de jeter à l'excès, je m'écarte du sujet).

Disclaimer : je n'y connais rien en C++ donc ce que je vais dire repose essentiellement sur ma compréhension de la documentation de shared_ptr.

Je tenterai de garder ça en mémoire, mais en retour, je te demande de tenter de garder en mémoire que je ne connais du OCaml que ce que j'ai cru comprendre au travers des discussions de linuxfr, c'est à dire quasi rien excepté quelques concepts hyper vagues (car je n'ai pas fait l'effort de m'investir). Si je me trompe, je compte sur toi pour pour me le dire. C'est à ça que sert un forum technique en même temps.

Ai-je bien compris le concept de shared_ptr

Je pense que non, mais je me trompe peut-être.
Je pense que la confusion viens du fait que les langages fonctionnels semblent (de ce que j'ai compris) favoriser la copie lors d'écriture et être optimisés pour ça. Ils masquent les mécanismes de bas niveau.

Le shared_ptr de c++ n'est rien d'autre qu'une zone mémoire qui est partagée entre plusieurs autres objets, et chacun peut y modifier les données. Jusque la, ça va encore.
Les problèmes:

• les autres propriétaires du shared_ptr n'ont aucune idée de la taille de la zone allouée.
• je ne crois pas qu'il y ait moyen de savoir si les données sont valables dans le cas d'un traitement multi-thread/process, car ce n'est vraiment qu'un fichu stupide pointeur!
• en admettant que l'on réussisse à contourner ces problèmes, j'attend encore de voir un code maintenable qui exploite cette fonctionnalité. Les standards décrivent ce que l'on peut faire, pas ce que l'on devrait faire, il est important pour moi de garder un esprit critique, même en étant moins intelligent que les gens qui font les standards.

sensibiliser à la problématique de la centralisation d'Internet ;

J'ai un point de vue personnel et peut-être éventuellement technique sur la question, qui fait que comprend pourquoi vous trouvez ça dangereux.

Du coup, si vous pouvez m'aider a avoir des pistes pour dire en quoi c'est une mauvaise chose qu'internet soit centralisé, et comment faire pour l'empêcher, avec en prime un impact négatif négligeable sur le coût financier (au moins technique, l'humain, ça peut se gérer je pense, en fonction de la situation) je vous serais reconnaissant.

Je ne dis pas que je ne suis pas reconnaissant envers framasoft.
Loin de là: vous hébergez l'un des sites qui m'on permis de passer d'un windows full propriétaire/cracké à un windows libéré. Je ne l'ai jamais dis, et je sais que c'est un tort car ça réchauffe le cœur, mais sachez que c'est en partie grâce à vous que:

1. je moule ici. Par une référence, certes.
2. j'ai eu un environnement de développement libre sous windows.
3. j'ai eu un bureau quasi libre sous windows.
4. je suis passé à Debian.
5. je suis capable de ne pas changer de PC tous les 3 ans.
6. je contribue de temps en temps, en code, à divers projets.

Je sais que la plupart de mon entourage n'en fera pas autant que moi, parce qu'ils n'auront pas les compétences, parce qu'ils ne considéreront pas que ça vaut le coup, etc.
Mais, ce que je trouverais utile, en plus de fournir des services utiles et d'essayer d'essaimer, c'est que vous nous enseigniez, à nous qui sommes d'accord avec vous, comment convaincre voire, pourquoi pas, persuader, nos proches d'adopter ces solutions, que ce soit en utilisant vos services ou des chatons.
Parce que mon avis, c'est que c'est ça qu'il nous manque: le savoir convaincre, et le savoir persuader (l'un et l'autre s'adressant à des catégories différentes).

Oups, pas vu qu'il y a la même réponse un peu plus haut…

Je suis d'accord, ce n'est pas possible et même probablement pas souhaitable d'avoir un truc unifié multi-arch.

Ceci étant dit, le mangling, justement, est ce qui force à repasser en mode "struct&pointers" quand on veut faire joujou avec des plug-ins, et l'on n'est même pas sûr que d'un compilateur à l'autre, voire d'une version à l'autre d'un même compilo, il ne faille pas tout recompiler.

Après, les exceptions… personnellement, j'évite, et si j'utilise, je ne les fais pas sortir de leur binaire. D'une part, je trouve pas ça si terrible que ça en terme de maintenance, et d'autre part, si une exception n'est jamais rattrapée, c'est un comportement indéfini, et comme elles ne sont pas toujours super documentées… je ne les hais pas, je m'en méfie juste.

mais c'est sans doute plutôt un manque de temps-développeurs qui explique ce retard.

Manque de temps qui à priori n'était pas facilité par l'absence de version stable à long terme.
En lisant le journal, je me suis justement dit que la grosse nouveauté était d'avoir une version qui sera maintenue officiellement pendant 18 mois: je suis certain que les mainteneurs Debian vont apprécier le geste.

Et puis pour revenir au C++, les on-dits et ce genre de dépêche ont un effet assez dissuasifs sur moi. Je suis plutôt à l'aise en C

Je vais en profiter pour parler de ce que j'apprécie dans le C++, ça changera du thread ou les défauts sont listés :)

Pour moi, les principaux avantages du C++ sur le C (qui à été mon 1er «vrai» langage), c'est qu'il permets d'automatiser plus le code source, sans forcément avoir recours à des trucs capilo-tractés. Certes, on peut faire des trucs complexes, mais tout ne l'est pas.
Typiquement, les 3 (5 en fait, si on compte le const_cast et le cast old school qui est toujours valide) casts de C++ ont un gros avantage sur celui du C, ils permettent d'éviter pas mal de bugs.

J'ajouterais en 2ème position les template.
Pas la STL (la STL, c'est un concentré de C++: classes, templates, exceptions), juste les templates (la SL possède de beaux exemples comme std::sort déjà mentionné) qui permettent de quasi-supprimer les macros, tout en permettant un code plus lisible et plus sûr (les types sont vérifiés à la compilation). Malheureusement, je ne crois pas (mais je n'ai pas vérifié) qu'il soit aussi simple de manipuler des chaînes de caractères de la même manière en template qu'en macros, donc ces derniers ont toujours leur utilité ( ## et #, même si c'est illisible, m'on déjà été utiles ).
Par exemple, j'ai un template qui permets de caster d'un type vers un autre, et si il y a dépassement (enfin, j'ai pas fait une couverture de test à 100% et j'ai testé que sur des pointeurs et des entiers), ça fait assert ratée. En release, ça ne fait que dalle. Accessoirement, il est plus court à taper que static_cast ;)
J'aurai sûrement pu coder ça à coup de macros, mais je pense que j'aurai dépassé la 60aine de lignes (et j'aime bien aérer en hauteur).

En 3ème position, les fonctions à l'intérieur des structures, plus clairement: les constructeurs et destructeurs: fini de devoir se rappeler d'appeler SDL_FreeFooBar(ptr);.
Contrairement à l'idée reçue, pas besoin d'exceptions ni d'héritage pour en tirer bon profit. Dans le cas de l'héritage, je dirais même que c'est de toute façon un truc que j'évite, comme probablement pas mal de monde et ce, dans tous les langages.
En standard, on a std::unique_ptr, mais, ça ne gère que les pointeurs (et ce n'est pas le seul reproche que j'ai envers unique_ptr, mais comme je l'ai dis, je ne considère pas la STL comme le principal point fort de C++, au risque de me faire descendre :)): pas les resources indexées (handles de fichier, de ressources OpenGL, whatever). Du coup, j'ai une classe qui gère l'unicité des ressources, et qui sait que -1, c'est l'équivalent de nullptr. Enfin, en réalité, elle ne le sait pas: je lui ai collé un paramètre template pour indiquer quelle valeur est équivalent d'une ressource vide.

4ème: la SL. C'est à dire la bibliothèque standard sans les conteneurs. Je ne dis pas qu'ils sont inutiles, mais ils ont les «inconvénients»:

• de lancers des exceptions (et on peut pas faire autrement) dans différents cas.
• de ne pas permettre de contrôler facilement l'usage mémoire (sauf std::array et, dans une moindre mesure, std::vector. std::map/set et leurs versions multi sont souvent implémentées en RBtree, pas sûr pour les unordered, et de toute façon le standard n'impose rien me semble).

En revanche, la SL, c'est des algo plus ou moins classiques et complexes à faire qu'on peut utiliser d'une ligne. Enfin, surtout depuis c++11, parce qu'avant les lambda et std::begin()/std::end() c'était un peu pénible :)

Le reste, pour moi, ce sont des plus, mais pas les killer features du C++ (surtout du point de vue d'un dev C, j'imagine):

Quand t'as la flemme de faire tes propres conteneurs, tu peux utiliser la STL.
Et si t'as envie de faire tes conteneurs (genre un ring buffer ou un dictionnaire dont on peut connaître l'usage mémoire), mais que tu ne veux pas réécrire les algorithmes standards, tu as juste à implémenter un itérateur: tu bénéficies toujours des algo de la SL.
Bien sûr, le récent fait de pouvoir utiliser les algo sur des tableaux C-style est bien pratique, ainsi que le range for (peut-être qu'il existe aussi en C11? Je ne sais pas du tout ce qu'ils ont ajouté.).
Et pour finir, les exceptions et les flux: beaucoup les aimes, d'autres non, mais dans certains tout ça est bien utile.

En conclusion: tu devrais essayer. Juste, dans un premier temps, remplacer gcc par g++ (ou clang par clang++ ou… bref) et les casts. C'est plus verbeux c'est vrai, mais ça réduit les problèmes.
Puis avec les templates et la RAII, tu te retrouves déjà avec des codes bien plus réduits que leurs versions C, sans être obligé de libérer explicitement les instances de BDD (chose qu'il faut faire manuellement tant en C qu'en Java si on se méfie du côté aléatoire du GC) et sans forcément avoir un code plus dur à lire, même s'il est vrai que plus on combine de techniques, plus le code deviens délicat à manipuler. D'où l'intérêt d'intégrer les avantages au fur et à mesure (et avec le temps de considérer certains morceaux comme peu utiles en regard des services rendus).

(par exemple, pourquoi les destructeurs ne sont-ils pas virtuels par défaut?)

Parce que la présence d'une méthode virtuelle implique la génération d'une vtable, qui a un impact sur les performances.

typiquement, les arguments de main

Portabilité & Compatibilité (oui, je sais) avec la famille execXY() standardisée par POSIX (ne pas oublier que la portabilité est importante pour les utilisateurs de C++).

Tu proposes quoi?
De renvoyer un bool et d'avoir un std::vector<std::string>const& en entrée?

Ça implique argc + 1 appels à new (puisqu'il faudrait copier ce que l'OS envoie, ces conteneurs n'étant pas capables de prendre la propriété d'un pointeur) pouvant throw en cas de problème mémoire. Et ou tu catch, puisque ça à throw avant même d'entrer dans le code?

Je ne mentionne pas le fait que std::string, c'est potentiellement 24 octets par objet (en plus du contenu, tu as en gros un pointeur vers les données, un vers la fin de la zone utilisable et un dernier qui indique la fin réelle. 3 * 8 sur une machine 64bits classique).
Si t'as en entrée un truc genre apt-cache pkgnames, ça risque de faire pas mal de mémoire (45237 entrée chez moi, autrement dit plus d'1Mio potentiels une fois *24. Je dis potentiels, parce qu'avec les SSO ça peut être moins, en fonction du compilo.) et de risques de throw, le tout pour faire plaisir à des gens qui n'ont rien à faire de la performance et de la portabilité, qui ne sont pas la cible première de C++?
Quel réel avantage y aurait-il? Au passage, std::basic_string<char> ou std::basic_string<wchar> (bon, j'ai un doute, je sais plus si c'est wchar ou wchar_t…)?

(personnellement, j'aime bien le comportement d'un bool qu'on a oublié d'initialiser)

Au moins n'est-il pas null, nil, nul ou whatever truc qu'on peut voir ailleurs. Ici, tu oublies un truc: en C++ on ne paye pas pour ce qu'on n'utilise pas. Et ce n'est pas toujours utile d'initialiser tes variables quand tu les déclares: par exemple une variable qui sera initialisée dans une boucle, et utilisée après la fin de cette boucle, il n'y a aucune raison de l'initialiser avant.
Au passage, ton compilo te préviendra pour 99% des cas (jusqu'à présent, il m'a toujours prévenu, mais bon, je laisse place à l'incertitude).

Il y a des gens qui "#include" des trucs autres que des .h?.

La plupart des développeurs C++.
Les fichiers de la SL n'ont pas d'extensions. Pas mal de libs utilisent ".hpp". On voit régulièrement ".tpp" pour les templates. Entres autres.
Mais honnêtement, ça ne me gênerait pas outre mesure que l'on ne soit plus obligé de se taper les header guards, bien au contraire.

Y compris dans la justification de la non-dépréciation de syntaxes obsolètes qui n'ont aucune justification (goto, void*, etc)

Hum. Goto, parce que tu le remplaces par les exceptions, c'est ça? Le support des exceptions augmente, selon un document que j'ai la flemme de rechercher, le binaire d'environ 10%. Pas forcément possible pour tout le monde. void*, ça nous permets de nous interfacer avec du C, avec des fonctions aussi «obsolètes» que dlopen.

Autant je te rejoins sur les header guards, autant pas sur les goto/void* (alors que je n'utilise pas goto et que je ne suis que client de void*).

Il y a du code de 40 ans qui compile grâce à ces trucs? Qu'est-ce qu'on s'en fout

C'est un point de vue. Pas celui de tout le monde.

Ce qu'on peut reprocher au C++, c'est de ne même pas définir la manière correcte de faire les choses

Java à interdit aux dév. de faire des fonctions. Résultat, ils font des classes statiques. Toutes les exceptions doivent être rattrapées? Ok, mais on ne fais rien.

Je parle de Java ici, mais c'est juste le 1er exemple qui me viens en tête. Quand un langage limite ses utilisateurs, ils contournent les limitations, parfois à bon escient (la classe statique, avec le main statique) parfois non (les exceptions) et dans tous les cas, je trouve que ça alourdit la lecture.
C++ n'est pas parfait niveau simplicité de lecture (surtout quand on lit du code template) mais j'apprécie qu'il ne me force pas à suivre une école de pensée unique, qui ne sera pas optimale pour certains cas particuliers.

L’usage d’une fonction clone est problématique aussi (qu’est censé faire Derived::clone(Base const& b) si on lui donne un Base& qui est de type Derived2 ? Un assert ? pas terrible…).

Je n'utiliserais pas la même signature moi, je ferai plutôt static bool Derived::clone( Base const& b, Derived& a ); du coup, tu fais ce que tu veux quand ça échoue, avec a qui n'est pas modifié si tu as fais les choses bien.

Personnellement, j'opte de plus en plus souvent pour l'usage de constructeurs nommés (static foo::make( ... );) et quand ça rate (paramètre foireux, initialisation impossible, whatever), selon mon API je throw ou retourne foo().
C'est un idiome plutôt pratique, qui peut palier à ton problème (si je l'ai bien compris) et même permettre d'avoir plusieurs «constructeurs» avec les mêmes signatures, exemple (bidon) si tu veux générer un pixel RGB, tu peux avoir 3 constructeurs nommés pour faire les nuances d'une couleur unique.
En bonus, dans certains cas, ça évite de se taper les operator= & Ctors, alors que l'on veux juste ajouter un moyen de convertir un type dans un autre. En malus, je "perds" une partie des conversions automatiques (enfin, surtout parce que j'ai souvent la flemme de me tapper les operator=&Ctors).

Ah bah merci, me coucherais moins bête :)

Le truc, c'est que le C est un langage tellement simple (pas d'héritage, donc pas de méthodes virtuelles donc pas de vtable, pas de RTTI, pas d'exceptions) que c'est relativement simple d'avoir des ABI compatibles (je ne dis pas qu'elles le sont toujours) entre divers fournisseurs.
C'est d'ailleurs pour ça que tout le monde passe par le C pour discuter les uns avec les autres.

Pour les autres langages, souvent plus riches en fonctionnalités, je dirais qu'il y a 2 cas:

Si on prend un langage «propriétaire», non pas dans le sens code source fermé mais dans le sens qu'il n'existe qu'un compilo et que c'est lui la norme, le problème se résous de lui-même.

Mais dans le cas d'un langage comme C++ (doit y en avoir d'autres je pense), qui est un standard ISO pouvant être implémenté par de nombreux acteurs et sur tout type de matériels, le fait de ne pas avoir d'ABI standardisée (dans les spec. du langage) me semble être un pré-requis, pour la faisabilité (diversité des acteurs, code fermé & P.I., etc.) comme pour les possibles optimisations dépendant des architectures. Enfin, pour les optimisations, c'est ce que je me suis laissé dire: n'y connaissant pas grand chose, je ne peux juger.

Et, dans le cas de ta critique, tu es dans la partie "souvent" ou dans l'autre? :D

D'une part, j'ai bien précisé: "je pense", je n'ai pas dit "c'est une erreur". La nuance est faible, mais existante: je n'ai jamais prétendu être bon, donc je peux penser des conneries.

Ceci étant dit, j'ai beaucoup de mal avec l'idée qu'un objet soit possédé par plusieurs autres à la fois, en terme de maintenance j'imagine mal ça simplifier les choses.

D'ailleurs, c'est assez amusant. Je me rappelle qu'au début je trouvais l'idée super. J'ai réfléchi à l'utiliser sans jamais y trouver d'usage mais je me disais juste que l'occasion ne s'était pas présentée. De fil en aiguille j'étais tombé sur un billet de blog ou l'auteur expliquait pourquoi il estimait que l'utiliser ne lui semblait pas une bonne idée. J'ai essayé de répondre à ses points (vu que je n'étais pas d'accord du tout), et, en répondant, je me suis aperçu que tous les arguments que j'avais en faveur du shared_ptr étaient mauvais. Du coup j'ai bien du passer 2H à ne rien répondre.

Après, peut-être qu'un jour je tomberai sur un cas d'usage réel, après tout, j'ai bien eu une fois un cas ou l'héritage en diamant m'a été utile (je ne dirai pas que ce cas était super bien ficelé, mais dans la situation c'était ça ou duplication d'une quantité de code assez conséquence comparé à la taille du projet)…

Pour conclure, je veux bien un cas d'usage quotidien de shared_ptr. Si je peux être détrompé, tant mieux.

quand on voit que les gens se peignent de Gnome 3

Ah ça… les goûts et les couleurs…

beaucoup de monde joue avec des sources qui sont en C++03, donc au revoir les smart-pointers.

Non, au revoir la move semantic, et donc au revoir std::unique_ptr.
Mais std::auto_ptr (maintenant déprécié car remplacé par unique_ptr qui est plus sûr, certes) existait déjà en C++03. Et c'était toujours mieux que d'utiliser des raw, mais personne ne l'utilisait. Probablement parce que, par exemple, les gens qui enseignent ne connaissaient pas nécessairement son existance (j'en ai jamais entendu parler à l'école, des pointeurs intelligents… de manière générale, on à très peu parlé de la lib standard, je ne sais vraiment pas pourquoi, ça aurait réduit pas mal certaines conneries).
Et pour ce qui est de shared_ptr, je pense que ce truc est une erreur, mais bon, un pointeur intelligent avec compteur de référence ce n'est pas ce qu'il y a de plus difficile à coder non plus.
Enfin, tant qu'on reste dans le mono-threadé ou si l'on accepte d'utiliser des libs externes: le multi-thread était inexistant avant C++11 après tout.

Ici, ça me semble clair: c'est B qui définit qui à le droit d'utiliser ses propriétés protégées. Le fait que D considère fr() comme une amie ne donne absolument pas le droit à fr() d'utiliser une propriété protégée de B, uniquement celles de D.
Donc pour moi, g++ à tort et clang++ raison. Et je doute que le standard ait changé sur ce point: il faudrait trouver un vieux compilo standard de l'époque pour etre sur.

Ceci dit, personne n'a dis que le C++ n'était pas trop compliqué. C'est de notoriété commune (et en plus maintenant on multiplie les façons de gérer un prototype de fonction avec le auto foo() ->type).
Une fois ajouté la dessus le fait que certains compilos vont ajouter silencieusement leurs tolérances et extensions si tu ne précises pas un standard, et tu multiplies les risques de confusion, sur un truc déjà complexe.