Le topic de la programmation, string, chaînes, cuir et compagnie

[Tomaka17]

non rétro-compatible)

Wat

Pour la première fois dans l'existence du C++ ils vont faire un changement non-rétro-compatible ?

[rOut]

L'introduction des concepts et leur application à la STL n'est pas viable sans risquer de casser du code. Donc ils sont ouvert à cette possibilité, quitte à distinguer la nouvelle librairie de celle legacy.

[Tomaka17]

Ils devraient appeler ça le "C++ with concepts", ou alors le C++++

[moimadmax]

C'est pas déjà le concept du C# les 4 + ?

[Sp1d3r]

http://www.microsoft.com/presspass/i...-c-sharp03.jpg

Non, c'est un dièse, même si on utilise plutôt # pour l'écrire.
Pour incrémenter une variable après avoir retourné sa valeur, on met ++.
Pour augmenter d'un demi-ton une note, on met un dièse. C'est un peu ça l'esprit.

[rOut]

So the naming committee had to get to work and we sort of liked the notion of having an inherent reference to C in there, and a little word play on C++, as you can sort of view the sharp sign as four pluses, so it’s C++++. And the musical aspect was interesting too. So C# it was, and I’ve actually been really happy with that name. It’s served us well.

[moimadmax]

Je savais bien que j'avais vu ça quelque part

[Tramb]

La communauté C++ est rigolote. Après nous avoir expliqué que l'objet était bien fait en C++, après nous avoir expliqué 15 ans que algorithm/itérateur c'était LA VOIE, après nous avoir vanté la généricité par template, après s'être branlés sur la meta Alexandrescu-like (LOLOLOLOL j'écris un parser en template c'est trop génial), on va nous expliquer que en fait il faut upper la sémantique d'un niveau pour avoir des ranges au lieu des itérateurs. Sans blague. A chaque itération on nous explique qu'il n'y a pas besoin de ce qu'il y a dans d'autres langages, oh la non, et 5 ans après, hop, on introduit des features pour faire pareil. J'attends map et foldl et C++ 2034. Et les slices de tableau en 2046.
C++, je suis fâché, j'aimerais te quitter après 20 ans de ménage. Mais bon, tu restes le seul langage portable qui se compile correctement partout.

[Tomaka17]

Le problème, c'est aussi que la lib standard a évolué avec ce truc.

- Les streams utilisent l'overloading des opérateurs << et >>, que tout le monde trouvait cool à l'époque mais dont tout le monde s'accorde à dire que c'était une mauvaise idée.
- Les streams utilisent également l'héritage, c'est la seule partie de la lib qui utilise cela.
- Les streams toujours utilisent des pointeurs bruts dans leur interface, c'est très pas C++11.
- Quand les exceptions étaient à la mode, ils se sont arrangés pour que new throw si jamais il y a une erreur d'allocation (un truc très controversé), là où maintenant c'est tout ce qui est "noexcept" qui est à la mode.
- En ce qui concerne les containers, ils ont décidé de faire des specs extrêmement précises, allant jusqu'à spécifier quelles fonctions invalident tels itérateurs sous telles conditions (c'est limite s'ils ne t'imposent pas le code C++). Alors que récemment ils ont rajouté une fonction "alien" très haut level nommée std::async, où tu ne sais même pas si elle créé un thread ou non.
- Au même moment où ils ont rajouté les "typedef templates" (using), ils ont également décidé de standardiser les work-arounds qui existaient à cause de ce manque, avec la syntaxe "std::machin_machin<T>::type".
- std::enable_if sera obsolète dès que les concepts auront débarqué, et en plus c'est pas comme s'ils ne savaient pas que les concepts allaient arriver au moment où ils ont rajouté enable_if.

Du coup on a cette stdlib très hétérogène, mais rétro-compatible. Et j'ai un peu du mal à comprendre pourquoi ils décident de casser la rétro-compatibilité pour un truc aussi insignifiant que les ranges plutôt que de tout remanier.

[Tramb]

Houla me parle pas des streams, rien que l'évocation du truc me donne des petits spasmes gastriques :-)

[rOut]

Je ne vois pas le problème d'avoir un langage qui évolue. OK on reprend des concepts existant ailleurs, et alors ? Au moins on ne pourra pas dire qu'il manque au C++ l'expressivité du langage X. Et ce qui est cool c'est qu'en plus en C++ ça va vite. Et dropper les concepts qui se sont avérés ne pas être aussi bien que ce qu'on pensait c'est faire preuve de réalisme aussi. Le jour ou ils repenseront le mécanisme d'allocateurs de la STL pour le rendre plus utilisable, qui s'en plaindra ?
Sinon pourquoi ne pas rester au C, y'a des gens qui pensent qu'effectivement tout ces ajouts c'est du bullshit et qui font ça.

---------- Post added at 11h50 ---------- Previous post was at 11h46 ----------

Le problème, c'est aussi que la lib standard a évolué avec ce truc.

- Les streams utilisent l'overloading des opérateurs << et >>, que tout le monde trouvait cool à l'époque mais dont tout le monde s'accorde à dire que c'était une mauvaise idée.
- Les streams utilisent également l'héritage, c'est la seule partie de la lib qui utilise cela.
- Les streams toujours utilisent des pointeurs bruts dans leur interface, c'est très pas C++11.
- Quand les exceptions étaient à la mode, ils se sont arrangés pour que new throw si jamais il y a une erreur d'allocation (un truc très controversé), là où maintenant c'est tout ce qui est "noexcept" qui est à la mode.
- En ce qui concerne les containers, ils ont décidé de faire des specs extrêmement précises, allant jusqu'à spécifier quelles fonctions invalident tels itérateurs sous telles conditions (c'est limite s'ils ne t'imposent pas le code C++). Alors que récemment ils ont rajouté une fonction "alien" très haut level nommée std::async, où tu ne sais même pas si elle créé un thread ou non.
- Au même moment où ils ont rajouté les "typedef templates" (using), ils ont également décidé de standardiser les work-arounds qui existaient à cause de ce manque, avec la syntaxe "std::machin_machin<T>::type".
- std::enable_if sera obsolète dès que les concepts auront débarqué, et en plus c'est pas comme s'ils ne savaient pas que les concepts allaient arriver au moment où ils ont rajouté enable_if.

Du coup on a cette stdlib très hétérogène, mais rétro-compatible. Du coup j'ai un peu du mal à comprendre pourquoi ils décident de casser la rétro-compatibilité pour un truc aussi insignifiant que les ranges plutôt que de tout remanier.

C'est pas à cause des ranges, c'est à cause des concepts. Mais les ranges seraient introduits au passage. Sinon mis à part sur les streams je ne suis pas d'accord avec les autres points.

[newbie06]

J'attends map et foldl et C++ 2034. Et les slices de tableau en 2046.

Et l'inférence de type généralisée c'est pour quand ?

[TiNitro]

Plutôt d'accord avec rOut, le langage évolue enfin, il y a un comité ISO, il font dans le rétro-compatible (c'est quand même l'ADN du langage, à sa naissance sans la rétro compatibilité C il n'aurait eu aucun succès le C++, on ferait tous du Objective-C).

Alors du coup, oui, logiquement il y a hétérogénéité dans la lib. Bon, je dors quand même bien la nuit hein.

Sur l'évolution du C++, je suis ça d'un peu loin vu que je ne code plus mais on sent des luttes d'influence dans le comité entre certains qui veulent aller vers le meta-pouet-pouet et ceux comme Soustrup qui veulent simplifier et rendre le langage plus accessible. Ça donne une stratégie pas ultra lisible mais c'est le prix de la démocratie.

Et oui, les range c'est un conséquence, pas une cause comme dit rOut.

La StdLib a été définie à une époque ancienne ou le comité ISOCPP n'existait pas et ou il y a sans doute eu des luttes d'influences occultes. C'est la lib RogueWave qui était prés-sentie pour servir de base à la bibliothèque template standard, et on a eu un drôle de truc bâtard à la place et il faut vivre avec. Et la lib RogueWave je l'ai utilisée en 92, alors l'absence de range ne m'avait pas parue être un scandale à l'époque voyez-vous.

[DM61]

Ca donne envie de se mettre au c++, rien que pour savoir d'où vient toute cette rage et douleur.

[Tomaka17]

En tout cas je ne trouvais pas que le C++ était un si mauvais langage que ça avant que je ne découvre le Rust.
Tous les problèmes du C++, je pensais que c'était une contre-partie au fait d'avoir des perfs maximales (c'est le crédo du C++ ; tout ce qui ralentit l'exécution est forcément facultatif). Sauf que le Rust fait la même chose mais sans les défauts.

[rOut]

Purée, en fait je sais. En Rust c'est pas les programmes qui plantent c'est la compilation. Je voulais voir un peu ou ça en était depuis la dernière fois que j'avais testé, tous les samples que je trouve me pètent des erreurs de compil...

---------- Post added at 19h10 ---------- Previous post was at 18h53 ----------

Rustc me vomit ça (y'en a des milliers de lignes) je ne sais pas d'ou ça vient, aucune des sources ne contient ça.

<quote expansion>:654:39: 654:48 warning: \U00ABCD12 and \uABCD escapes are deprecated
<quote expansion>:654                     '\U000e0100' ...'\U000e01ef' => true,
                                                            ^~~~~~~~~
<quote expansion>:654:39: 654:48 help: use \u{ABCD12} escapes instead
<quote expansion>:654                     '\U000e0100' ...'\U000e01ef' => true,
                                                            ^~~~~~~~~

Et puis sinon c'est grosso modo des erreurs au sujet de moves invalides.

src/x11/window/mod.rs:105:54: 105:78 error: cannot move out of dereference of `*`-pointer
src/x11/window/mod.rs:105                 let mode: ffi::XF86VidModeModeInfo = **modes.offset(i as int);
                                                                               ^~~~~~~~~~~~~~~~~~~~~~~~
src/x11/window/mod.rs:105:21: 105:25 note: attempting to move value to here
src/x11/window/mod.rs:105                 let mode: ffi::XF86VidModeModeInfo = **modes.offset(i as int);
                                              ^~~~
src/x11/window/mod.rs:105:21: 105:25 help: to prevent the move, use `ref mode` or `ref mut mode` to capture value by reference
src/x11/window/mod.rs:105                 let mode: ffi::XF86VidModeModeInfo = **modes.offset(i as int);
                                              ^~~~

[Sahnvour]

En tout cas je ne trouvais pas que le C++ était un si mauvais langage que ça avant que je ne découvre le Rust.
Tous les problèmes du C++, je pensais que c'était une contre-partie au fait d'avoir des perfs maximales (c'est le crédo du C++ ; tout ce qui ralentit l'exécution est forcément facultatif). Sauf que le Rust fait la même chose mais sans les défauts.

Et qu'il est pas encore stable. Mais niveau perf ça donne quoi, le compilateur produit du code aussi optimisé qu'un GCC ?


Et d'où vient cette haine des opérateurs << >> sur les flux ? (question naïve)

[TiNitro]

oui, c'est une bonne question . D'autant que comme tout opérateur, c'est juste un sucre syntactique pour appeler des fonctions.

[Tomaka17]

Purée, en fait je sais. En Rust c'est pas les programmes qui plantent c'est la compilation. Je voulais voir un peu ou ça en était depuis la dernière fois que j'avais testé, tous les samples que je trouve me pètent des erreurs de compil...

Ouai le problème pour l'instant c'est que tout code Rust qui date de plus d'une semaine ne compile plus. Mais c'est de plus en plus rare, en ce moment les libs tiennent parfois un ou deux mois sans casser.

Et puis sinon c'est grosso modo des erreurs au sujet de moves invalides.

Ah merde c'est une lib à moi ça :D
Il y a sûrement un breaking change dans une des dernières versions du Rust, ma version date du 8 décembre.

---------- Post added at 19h31 ---------- Previous post was at 19h28 ----------

Et qu'il est pas encore stable. Mais niveau perf ça donne quoi, le compilateur produit du code aussi optimisé qu'un GCC ?

C'est un backend LLVM, donc oui.
Après comme dans tous les benchmarks, parfois c'est le C/C++ LLVM qui gagne, parfois c'est le C/C++ gcc qui gagne, parfois c'est le Rust.

Et d'où vient cette haine des opérateurs << >> sur les flux ? (question naïve)

Le problème c'est que tu inventes une syntaxe.

C'est bien d'implémenter les opérateurs si ton implémentation a exactement le même effet que l'opérateur de base.
Par contre si au lieu d'écrire "void create_connection(int)" tu décides d'écris "void operator+=(int)", et que tu te connectes en écrivant "Ip(127,0,0,1) += port", là il y a un problème.

[rOut]

C'est quoi l'effet d'un opérateur de base ?

En quoi le + entre deux string a-t-il la même signification que le + entre deux integers ? Si ton langage a des vecteurs dans ses types de base, comment définis-tu l'opérateur * dessus ? Un produit vectoriel ? Un produit scalaire ? Une multiplication composante par composante ?

Tu dois toujours faire un choix, et à partir du moment ou tu autorises la redéfinition des opérateurs (et c'est le cas en Rust aussi semblerait-t'il, vivement les iostream), tes opérateurs ont une sémantique distincte par catégorie de types. Ca demande un minimum de rigueur pour ne pas obtenir un gros sac de noeuds, mais c'est tout à fait gérable.

Si ça te gène d'avoir une sémantique distincte pour une catégorie, alors il ne faut pas permettre la surcharge, et n'implémenter que les + * - / pour les types numériques, un opérateur de concaténation distinct pour les chaines et puis c'est tout. Tout le reste devra se faire avec des fonctions comme en Java, avec la lourdeur syntactique que ça apporte.

N'importe quel développeur C++ avec un peu d’expérience fait immédiatement la différence entre un << utilisé entre un stream et un argument à sérialiser dans le stream, et un shift appliqué sur un entier.

---------- Post added at 19h47 ---------- Previous post was at 19h43 ----------

Ouai le problème pour l'instant c'est que tout code Rust qui date de plus d'une semaine ne compile plus. Mais c'est de plus en plus rare, en ce moment les libs tiennent parfois un ou deux mois sans casser.

Serieux, comment peux-tu bosser avec un truc comme ça, tu dois passer ton temps à corriger le code existant.

[Tomaka17]

À une époque, oui je passais en moyenne 15-30mn chaque matin à corriger toutes les libs. Ce sont jamais de gros changements. Mais comme dit c'est de plus en plus rare.

Pour te donner une idée, voici une lib qui n'a quasiment que des corrections vis à vis du compilo et qui a la réputation de casser très souvent : https://github.com/netvl/xml-rs/commits/master
On a des mises à jour le 10 octobre, 22 octobre, 26 octobre, 30 octobre, 4 novembre, 5 novembre, 7 novembre, 17 novembre, 18 novembre, 8 décembre, et 9 décembre. Ça c'est un peu le pire du pire. Et encore souvent les changements passent une phase de déprécation où tu te tapes juste un warning.

Donc on va dire que "ça va".

[Sekigo Le Magnifique]

Perso, je ne vois pas le problème de Rust qui pète sans arrêt. Il est pas stable, je pense que c'est dit assez clairement dans la doc et sur le site, et il semble y avoir une roadmap définie. Le langage m'intéresse pas mal, mais j'attends qu'il soit en version stable pour tester pour de vrai, parce que je ne suis pas masochiste comme Tomaka.

Sinon, j'ai croisé sur reddit un framework web en python crée par l'entreprise qui a crée CMake.
Je ne connais pas CMake, mais vu que ça semble pas mal utilisé, je me dis que ça doit être un framework avec de nouveaux trucs ou des perfs de malade.
Je suis assez dubitatif. J'ai lu la documentation, et en gros, je ne vois pas l’intérêt de ce machin. C'est une sorte de pont entre les scripts cgi et un framework qui exploite wsgi. Et bien évidemment, on se tape les mêmes inconvénients des trucs plus évolué comme flask (pour déployer, c'est pas du drag&drop sur le serveur à la php ou cgi) sans avoir les avantages de cgi. Il montre des trucs sur leur site, avec des graphiques générés à la volée, de la visualisation de données, etc. mais je ne vois rien de folichon et qui ne soit pas déjà facilement utilisable avec un framework wsgi ou avec un script appelé en cgi. Ils ont l'air d'avoir passé pas mal de temps sur leur bidule, et je trouve que c'est vraiment du temps perdu pour rien à réinventer la roue. Et pourtant, c'est très très rare que j'ai ce sentiment.
Y a un simili système de webservice à la soap ou xml-rpc, mais je ne vois pas l’intérêt de ne pas utiliser ces derniers et de passer à un truc qui n'apporte rien de fondamentalement nouveau. En plus, les webservices de ce type sont déjà intégrés dans tous les frameworks wsgi.

[TiNitro]

Je viens de passer un peu de temps sur le site de rust, c'est effectivement intéressant.

Il n'y a plus qu'à attendre qu'un des géants de l'informatique l'adopte pour qu'il survive et qu'on voie un écosystème se développer autour.
Dans l'état actuel, je ne me vois pas engager l'avenir de ma boite sur une technologie dont les chances de survie sont aussi faibles. C'est un cercle vicieux, je sais.

[rOut]

C'est Mozilla derrière, donc ça va quand même. Ils développent le successeur de Firefox avec.

Sinon je dis pas que c'est surprenant qu'il change tout le temps, juste que Tomaka vient nous dire que c'est merveilleux et qu'il faut faire du Rust tout de suite, et que c'est peu être pas aussi merveilleux que ça pour l'instant.

[TiNitro]

ah ouais, ça va même mieux plutôt deux fois qu'une

Non, Mozilla ça ne va pas, ça veut juste dire qu'il y a des moyens et de cerveaux. Mais ça ne veut pas dire que j'aurais un jour un Framework ou une library standard stable qui me permettent de faire des GUI, du WEB, de la persistance, de l'accès aux données gnagnagna.

ça ne veut pas dire qu'un bug bloquant sera corrigé sous 48 heures.

Ça ne veut pas dire que dans 2 ans Mozilla ne va pas laisser tomber.

Donc, non seulement c'est pas le pied d'utiliser rust tout de suite (à part à titre perso et pour se faire plaisir), mais c'est vraiment beaucoup trop tôt pour engager une entreprise sur ce langage. C'est moche mais c'est comme ça, mais le comité ISOCPP s'est rendu compte que ce qui manque le plus à C++ c'est une bibliothèque comparable aux framework Java ou .Net. Il y a un effet "masse critique" difficile à atteindre.

Alors j'espère très fort que le C++ de demain ce soit rust. Mais j'ai un vieux doute.

[rOut]

Non, Mozilla ça ne va pas, ça veut juste dire qu'il y a des moyens et de cerveaux. Mais ça ne veut pas dire que j'aurais un jour un Framework ou une library standard stable qui me permettent de faire des GUI, du WEB, de la persistance, de l'accès aux données gnagnagna.

ça ne veut pas dire qu'un bug bloquant sera corrigé sous 48 heures.

Ça ne veut pas dire que dans 2 ans Mozilla ne va pas laisser tomber.

Heu, qui est-ce qui te garantit ça actuellement ?

[Orhin]

Microsoft avec le C# ?

[Sekigo Le Magnifique]

Je pense quand même qu'il y a de la marge entre "tester sérieusement pour des projets perso/pro" et "déployer dans mon entreprise 1000+ personnes en foutant le reste à la poubelle"...
Parce que sinon, on reste tous au Fortran (et encore, il continue à évoluer, me semble-t-il). C++/Java aussi, ça évolue. J'imagine bien qu'on ne code plus de la même façon qu'il y a 10 ans.
Quand je regarde les codes php de ma boite qui sont du mauvais code d'il y a 10~15 ans en php, et les codes plus ou moins potables qui sont fournis par les prestataires externes avec des techniques d'aujourd'hui, il y a un gouffre. Presque un autre langage.

Donc, quand Rust sera stable, il faut pas non plus jouer les timorés sans donner sa chance ou sans tester dans un projet de moyenne envergure. Évidemment, si il s'agit d'un système critique d'une centrale nucléaire ou de la bourse mondiale, il faut. Mais dans 99% des cas, que ce soit sur une vieille techno ou une récente, ça changera pas grand chose. Le langage sera toujours vivant quand le projet sera mort (sans évolution, il a atteint son but et il y a rien de plus à apporter)/réécrit.

[TiNitro]

@Ohrin : oui en effet, ça ne me fait pas plaisir mais l'écosystème est la, et même si Microsoft se découvre une nouvelle passion, la plateforme .Net va vivre et évoluer pendant plusieurs années, c'est certain.

@Sekigo: je bosse pour un éditeur de logiciel. On ne réécrit pas la totalité du logiciel tous les ans, si je décide de faire une nouvelle version sur une nouvelle technologie, c'est un investissement critique, et qui doit être pérenne. Nous n'avons pas les moyens de tout réécrire tous les 3 ans. Ni même tous les 5 ans.
Aujourd'hui, si je dis ok on fait du Rust, outre le fait que je suis obligé d'écrire énormément de code faute de bibliothèques sérieuses disponibles, si dans 3 ans le langage est abandonné par la mozilla, j'aurais coulé ma boite, sur un coup de Poker. Désolé d'être timoré.

Alors pour un projet interne de dimension raisonnable pourquoi pas, si effectivement la durée de vie du projet est courte.

@rOut: rien ne me garantit formellement rien, mais C++ n'est pas prêt de disparaître ni d'arrêter de progresser, il y a un sacré écosystème derrière C# d'autant qu'il est devenu open et sera disponible su de nombreuses plateformes. Idem pour Java.

Je juge en fonction de mes propres contraintes évidemment, mais s'il n'y a pas une masse significative de projet qui se font sur un langage, il finit par mourir. A petit feu, mais quand même.

[moimadmax]

Bon ben il est pas sorti le futur firefox si il faut revenir sur tout le code tout les 10 jours.
Après, dites moi si je me trompe, mais Rust n'apporte qu'un confort de programmation, niveau exécution il sera au niveau d'un programme en C++.

Finalement c'est le jeu des langages informatique, de manière général, plus c'est performant à l'exécution, plus c'est dur a coder. C'est toujours un ratio perf / Facilitées de programmation (inclus portabilité et tout ce qui peut y avoir autour):

Assembleur -> Rapide mais faut s'accrocher.
.
.
.
.
Python -> Facile mais en retrait niveau perf.

Bien sur certains langage s'en sorte mieux que d'autres. Je pense que c'est ce qu'essai de faire Rust.