lmg HS a écrit 174 commentaires

Il y a aussi moyen de rajouter
- aap (de Bram Moolenaar), assez similaire à scons dans mes souvenirs dans les grands principes de fonctionnement
- jam et bjam ; bjam est ce qui est utilisé par boost (.org)

Et ?
Aucun des langages mainstreams qui joue dans la même cours que lui (relativement aux d'applications types) n'est fonctionnel. Est-ce parce qu'il existe des langages dédiés qu'il ne devrait pas offrir des éléments d'un nouveau paradigme ?
Ca serait idiot.

(je réponds ici car les 150 niveaux d'indentation deviennent illisibles)
GC et smart-pointers, il y a quand même des différences:
- Un GC, maintenant, sait gérer tout seul les cycles ; à contrario des pointeurs à comptage de référence, avec lesquels il faut s'aider de weak_ptr ou assimilé
- Un GC ne finalise (comprendre: "détruit") pas l'objet pointé à contrario de tous les smart-pointers du C++.
- Tous les smart pointers ne sont pas à comptage de référence. La veille définition, c'est qu'un pointeur non brut/nu est smart/intelligent. Ainsi std::auto_ptr est un smart-pointer, tout comme boost::scoped_ptr, ou std::unique_ptr. [J'ai un peu de mal à voir pourquoi ces pinaillages autour des compteurs du coup]
- Les *_ptr<> de boost (et de C++11) peuvent encapsuler autre chose que de la mémoire, et ça c'est classe: nous avons ainsi des scoped_guard. Un GC ? Même pas en rêve. Il ne connait que la mémoire.
- Après je me souviens de discussions sur fclc++ ou clc++m où un avantage était prêté aux GC : le MT car ils n'utilisaient pas de compteurs atomiques.

OK, ils ont une fonction commune : la restitution implicite de la mémoire quand plus rien n'y fait référence ; de suite pour les smart pointer (déterministe), un jour pour les GCs (non déterministe). Et c'est tout. Sorti de ça, ce n'est pas du tout pareil.

Grosse parenthèse: close lèvera une exception uniquement si le flux est configuré pour lever des exceptions. Ce n'est pas le défaut.
Petite parenthèse, c'est RAII, pas RIAA (c'est pas l'asso de majors du disque ça ?), voire même RRIF (Resource Release is Finalization) si on veut se la jouer pédantique et confiner le RAII à son emploi premier. Bref.

Dans l'absolu tu as raison. Il y a un risque en cas de restitution problématique de ressource quand un échec est plausible. C'est pour cela qu'il est exigé qu'un destructeur ne doive jamais lever d'exception. Et encore, il me semble avoir vu des changements à ce sujet dans le prochain standard. Il faudrait que je remette la main dessus.

Maintenant, le "je ne peux pas fermer le fichier/la socket", honnêtement, cela passe toujours à la trappe, car même si on ne peut pas le fermer, on ne peut rien en faire non plus, et je ne connais pas de programme qui le gère correctement, même avec codes de retour. Des noyaux/bibliothèques peut-être pour faire remonter l'information jusqu'à l'appelant, qui bien souvent n'en fera rien.

Mon expérience est qu'ignorer une restitution refusée est généralement moins grave (et encore moins probable) que de laisser s'échapper une ressource. D'où que : le RAII suffit amplement. Que les débutants commencent par apprendre à s'en servir, on passera à l'étape suivante après.

Son intérêt est limité. C'est pour cela qu'il n'a pas rejoint le standard. std::unique_ptr<> remplit non seulement le rôle du boost::scope_ptr<>, mais aussi de std::auto_ptr<>. D'où le dialogue de sourds avec Batchyx je sens.

Sans parler de l'indispensable STLfilt. Les noms de types à rallonge ne sont pas un vrai problème avec les bons outils.

C'est unique_ptr<> qui a rejoint le standard, pas scoped_ptr<> qui ne peut pas être déplacé.

C'est ça: il faut passer par des variables intermédiaires.
Quant au sagouinisme, je suis sûr que l'on peut trouver des avantages aux temporaires non nommés, entre d'autres circonstance.

Comment peut-on avoir du code significatif avant la première insertion ? S'il y en a, le vecteur n'existera alors même pas chez moi. Le moment où le vector est vide est anecdotique au cours de l'exécution du programme. Il est fait pour fonctionner initialisé avec des données dans ses tuyauteries, et pas à vide.
Du coup le hack du pointeur sur vecteur ressemble(rait) plus (avec mes données et algos métiers) à une pessimisation, en volume de RAM consommée, qu'autre chose.

Et il n'y a pas d'alloc sur vecteur vide: push_back fait toujours un check de capacité, autant le laisser faire son boulot. Il y a juste l'init de 2-3 membres.

OK, disons que 16 bytes sont économisés dans le cas où il est vide. Dans le cas contraire on a un surcout de 8 bytes.
Franchement, ce n'est rien. A moins d'avoir un millier de vecteurs vides en même temps -- mais là cela sent le problème de design ou de choix de structures (typiquement c'est pas le plus adapté aux matrices creuses) -- ce n'est pas un surcout pertinent je trouve. Sans parler que mes vecteurs sont plus souvent pleins que vides, donc je serais en situation de surcout permanent avec un tel choix.

De plus, on perd en perf
* tests de non-nullité systématiques avant utilisation
* new + delete de plus
* potentielles indirections supplémentaires sur accès

Pour le NRVO, il y a toujours le passage par référence si on a peur de l’inapplicabilité du principe avec notre compilo -- le vieux sun CC m'avait d'ailleurs surpris à ce sujet sur des vecteurs et un code pas du tout torturé pour gagner l'optimisation. Et cela dégradera moins les perfs que des allocations dynamiques de vecteurs. (NB: maintenant, cet argument ne va plus tenir ; mais je me répète)

Plein ? Pas vraiment.
Je ne vois que :
* faciliter des déplacements en l'absence de rvalue-reference quand on n'a pas accès au (N)RVO, que l'on ne veut pas du COW (copy-on-write), ou que l'on veuille voyager entre scopes de façon pas si triviale (mais là cela sens l'abstraction moisie si vous me permettez)
* les TLS, quand on ne dispose pas d'abstractions de haut-niveau.

Un vecteur est déjà une allocation dynamique, qui par dessus le marché est RAII. Vouloir rajouter une seconde couche de dynamique et faire sauter le RAII de surcroit ? Oui mais non. Ce n'est pas fréquent que cette approche soit la bienvenue. Au contraire, c'est un pur code-smell en ce qui me concerne.

Le problème apparait dans ce cas d'utilisation:

void f(smart, smart);
...
f(smart(alloc()), smart(alloc()));

Si les fonctions d'allocation peuvent lever une exception (typiquement new, voire même un constructeur, peut échouer), vu que le C++ n'apporte aucune garantie ici quant à l'ordre d'exécution des opérations (le compilo est libre de réordonner pour maximiser les perf), on peut se retrouver avec la première allocation réussie, mais non récupérée par sa capsule RAII (smart), et la seconde allocation échouée. Résultat des courses, une fuite de ressource.

PS: je m'étais planté pour COTS, c'est commercial off-the-shelf. Composant, c'est dans la VF.

Mal, parce que les conteneurs sont déjà RAIIens. Du coup les allouer comme ça, cela brise les bonus de l'objet. Tu connais auto_ptr, c'est bien (car tu vois donc où je voulais en venir -- accessoirement, deux smart-ptr en paramètres sont un problème, cf XC++/GOTW/ou artima je ne sais plus -> Law Of the Big Two). Avec la prochaine norme, on y gagnera le déplacement (et donc encore moins de raisons valables d'allouer des conteneurs via new).

Oui, pour le slicing. Le rapport, c'est que le "taboo" est lié à un cas d'utilisation mal venu. Les conteneurs sont prévus pour être manipulés par valeur.
Le slicing est réel. Après l'autre exemple de non supplantation de [] est aussi très pertinent (du ridicule de la surcharge).

Mais ... pourquoi s'échine-t-on à parler des mauvaises solutions ? Au lieu de l'extension par fonction libre, ou des STL checkées ?

COTS:component off-the shelves ; en gros un truc externe payant (lib, programme, etc), mais régulièrement étendu à "truc externe" au projet.

Non, nous nous retrouvons avec un car.doStuffOnFirstWheel(). La clé est bien de penser en termes de services, et non en termes de données.

Si les développeurs commencent à faire des new sur des vecteurs même pas hérités, la dérivation publique de std::vector<> sera le moindre des problèmes.
Dans l'absolu tu as raison, mais en sortant du contexte académique, cela passe...

...presque. Le hic probable qui va planter les dév qui savent qu'on ne doit jamais faire de new sur un conteneur de la STL (et cf mon message précédent), est le suivant

std::vector<int> /*&&*/ cots::f();
void cots::g(std::vector<int> v); // copy-elision volontaire
...
MyVector<int> v = cots::f(); // copy-conversion
// certes, on va plutôt jouer avec [] et pas avec le C++ avec un type pareil...
v.erase(
    std::remove_if(
        v.begin(),v.end(),
        [&](int i){i>42)}),
    v.end());
g(v); // et re: copie-conversion

On va se payer des conversions dès que l'on va devoir récupérer des vecteurs depuis des bibliothèques déjà établies.
BTW, autant retourner at() qui fait mieux le boulot, ou obliger à l'utiliser si c'est pour faire du défensif plutôt que pour assurer de la prog par contrat... (où assert eut été une bien meilleure solution qu'une exception)

Dans ce cas là, cela ne poserait pas trop de problèmes, mais il est vrai que dans l'absolu c'est mal venu, et que l'on préfèrerait dans ce cas passer par une fonction libre inlinée qui réalisera le check par assertion d'abord plus éventuellement exception si on veut coder défensif -- pour le défensif toujours, il y a at(). Fonction dont l'utilisation peut être rendue obligatoire par des règles de développement pour le projet.
Maintenant, je l'ai déjà signalé, les STL checkées sont déjà là pour répondre à ce besoin.

Un tableau à 5 dimensions ... hum hum. Perso, j'appelle ça un code-smell, mais passons vu qu'à 2 voire 3 dimension, il y a un besoin pertinent.
Un proxy, cela va être quoi ? Un pointeur encapsulé dans une variable copiable, et qui expose un accès indexé. Ouais, un pointeur quoi.
Éventuellement un taille en plus. C'est ça le problème ? En quoi c'est différent de que que d'autres langages vont fournir en natif?
(Sans parler, que diverses bibliothèques vont déjà fournir tout ce qu'il faut pour enchainer les [], et ce de façon transparente.)

Ca marche très bien. Retourne des proxys et puis basta.
Ce sera juste un chouilla moins efficace.

Des implémentation checkées de la STL vont permettre de réaliser les vérifications de bornes. Ainsi en phase de développement et de tests on pourra consolider les accès.
Et en phase de production, on a aura les perfs.
Maintenant si on pense que les dév sont trop des gorets, et qu'il font n'importe quoi, on peut en prime faire de la prog défensive qui vérifiera les bornes aux endroits vraiment critiques, et pas dans une boucle "for_each(v.begin(),v.end(),[&]{actions});" où cela serait totalement idiot.

Il faut surtout être maso pour se passer du RAII en C++. Les "if (code_retour == pas_bon) goto error;", merci bien, mais plus pour moi!

Je vois un argument non-technique et pourtant essentiel qui a été passé sous silence -- car, bon il faut être honnête, il y a du bon et du mauvais dans les divers frameworks/bibliothèques existants.

Boost, c'est le labo du prochain standard. En gros, ce qui rejoint boost peut finir par être étudié pour rejoindre la prochaine norme du langage. C'est ce qu'il s'est passé avec plusieurs des sous-projets de boost : les pointeurs intelligents, les threads (dans une certaine mesure), bind et function, regex, etc. Qt ? GTK ? Ben ... Je me trompe peut-être, mais je n'ai pas vu de papiers émanant de chez eux pour proposer des évolutions dans le langage, ou ne serait-ce juste dans la SL. Alors, mieux ? Moins bien ? Peu importe, c'est ce qui se rapproche le plus du standard, ce qui capitalise le plus sur le standard. C++/Qt, c'est un peu comme C++/CLI, un truc langage différent avec ses idiomes qui lui sont propres. C++/SL+boost, c'est standard et valable partout (j'utilise même des morceaux de boost sur un fichu ARM avec l'archaïque gcc 2.95)

Une bibliothèque pour les diriger toutes ? Oui, en quelque sorte.

Hum... Arrêtez-moi si je me trompe.

Nous avons donc un outil qui permet de centraliser et manipuler des analyses produites par d'autres outils.

S'il s'agit bien de cela, en termes de C++ l'intérêt me parait bien limité vu que nous n'avons toujours rien capable de s'attacher à ce qui est important (i.e. le genre de règles que l'on va trouver dans le C++ Coding Standard de Sutter et Alexandrescu -- certes cppcheck a quelques vérifications sympa, mais il reste un sacré chemin à faire)

Pour le refactoring sous vim, il y a une solution assez complète pour Python évoquée plus haut, et ceci [http://code.google.com/p/lh-vim/wiki/lhRefactor] pour lequel j'espère faire une release bientôt (il faut que je me motive à terminer les docs). Un bémol pour l'extraction de fonctions, je n'ai pas encore intégré ctags pour déterminer les variables entrantes/sortantes relativement au bloc de code extrait.

La seule nouveauté intéressante ? Les concepts ne sont pas vraiment le truc qui servirait à tout le monde.

On ne les aura pas ? Pas grave, STLfilt suffira à 99% des développeurs C++. Le SFINAE servira au 1% (et encore) qui fait de la méta-prog.

En revanche, les ajouts à la bibliothèque standard, l'arrivée des threads et des quelques patterns/facilités qui tournent autour, et des sucres syntaxiques (nullptr, for, >sans espace>, ...) serviront à beaucoup.

Quant à rvalue-references vs COW/expression templates, je me demande bien lequel retourne le plus de l'obfuscation ... Personnellement, j'ai choisi mon camp.

Plus les lambda qui rendront enfin les algorithmes utilisables, au détail que comme en Perl il faudra apprendre à se restreindre.

Quant à la critique "pensé pour être utilisé", c'est justement pour cela que les concepts ont été rejetés : il n'y a aujourd'hui aucune expérience validée de leur utilisation (i.e. un prototype fonctionnel). Ils ne voulaient pas re-commettre l'erreur déjà faite avec les spécifications d'exception ou export.