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

[Tomaka17]

Les mecs qui bossent sur Servo se lockent sur une version de Rust particulière et forkent toutes les libs qu'ils utilisent, de façon à être stable.
Le projet Cargo quant à lui se locke sur une version de Rust et ne fork pas les libs, du coup ils sont obligés de mettre à jour le code quand ils veulent un changement dans une des libs qu'ils utilisent.

Quand au comparatif des langages, je dirais :
- Assembleur : Rapide, difficile, et produit du code qui contient de nombreux bugs
- C : Rapide, moyennement dur, et produit du code qui contient de nombreux bugs
- Python : Plus lent, facile, et produit du code relativement safe
- Rust : Rapide, difficile, mais produit du code légèrement plus safe que le python (grâce aux vérifications compile-time)

[Orhin]

Et le PHP dans tout ça ?

@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.

Clairement, on peut critiquer Crosoft sur pas mal de points mais y'a eu un gros boulot du côté .Net et des différents framework disponibles.

[fougny]

Les mecs qui bossent sur Servo se lockent sur une version de Rust particulière et forkent toutes les libs qu'ils utilisent, de façon à être stable.
Le projet Cargo quant à lui se locke sur une version de Rust et ne fork pas les libs, du coup ils sont obligés de mettre à jour le code quand ils veulent un changement dans une des libs qu'ils utilisent.

Quand au comparatif des langages, je dirais :
- Assembleur : Rapide, difficile, et produit du code qui contient de nombreux bugs
- C : Rapide, moyennement dur, et produit du code qui contient de nombreux bugs
- Python : Plus lent, facile, et produit du code relativement safe
- Rust : Rapide, difficile, mais produit du code légèrement plus safe que le python (grâce aux vérifications compile-time)

C'est marrant, moi j'ai toujours pensé que ce qui produisait du code avec des bugs c'est le truc qui se trouve entre la chaise et le clavier.
Mais je dois être trop vieux jeu.

[Tomaka17]

C'est marrant, moi j'ai toujours pensé que ce qui produisait du code avec des bugs c'est le truc qui se trouve entre la chaise et le clavier.
Mais je dois être trop vieux jeu.

À compétence/connaissance/expérience égale, tu écriras forcément plus de bugs en assembleur qu'en python.
Parce que c'est plus compliqué, parce qu'il n'y a pas de vérification, parce qu'il y a beaucoup plus de paramètres à prendre en compte, etc.
Tout comme tu écriras forcément plus de bugs si tu écris directement du langage machine en hexadécimal ou en faisant des trous dans des cartes plutôt que de coder en assembleur.

[rOut]

Ouais enfin tu n'as pas la même expressivité non plus. Pour un algo donné tu auras besoin de beaucoup plus de lignes de code en assembleur. Pour un développeur aussi compétent en asm qu'en python je ne suis pas sur que le nombre de bug moyen par ligne de code soit très différent.

[fougny]

J'avais compris ou tu voulais en venir koma, c'était juste une pique sur la phrase 'le C produit plus de bug' .

Sinon Je pense surtout que les bugs détectés seront des bugs purement techniques (allocation mémoire et ce genre de choses) qui sont, si le programmeur connait un peu le langage, les plus faciles à corriger (et les plus faciles à éviter).
Le compilateur ne protégera jamais contre les bugs fonctionnels. Ceux la ne disparaîtront pas par la magie du compilateur.

[Tomaka17]

Interdire les variables statiques, interdire le fait de pouvoir représenter des états invalides, etc. peut contribuer à produire moins de bugs fonctionnels.

[rOut]

Je ne sais pas si on peut faire une distinction claire, mais à mon avis ça reste des bugs techniques, pas des bugs de logique.

[Tramb]

Sinon Je pense surtout que les bugs détectés seront des bugs purement techniques (allocation mémoire et ce genre de choses) qui sont, si le programmeur connait un peu le langage, les plus faciles à corriger (et les plus faciles à éviter).

Si les buffer overflow, race conditions et autres double free étaient si faciles à éviter avec un peu de discipline, ça se saurait, et Internet serait moins une jungle.

[Sahnvour]

Pas encore lu, mais puisque c'est dans le sujet : http://kukuruku.co/hub/rust/comparing-rust-and-cpp

[rOut]

Non, c'est de la merde.

---------- Post added at 20h11 ---------- Previous post was at 20h09 ----------

Plus précisément le mec a un gros biais dès le départ et quasiment aucun des exemple pris n'est "fair", et encore moins l'analyse qu'il en fait.

---------- Post added at 20h15 ---------- Previous post was at 20h11 ----------

D'ailleurs le plus ironique c'est que niveau message d'erreur cryptique, Rust est en pleine compétition avec les messages à rallonge des templates (qui font peur parce que verbeux mais qui sont pourtant très clair, c'est la plupart du temps une stack d'instanciation ou une liste d'overload possibles, et la plupart du temps la première ligne suffit à identifier l'erreur)

http://is.gd/osqWJI

<anon>:5:19: 5:23 error: missing lifetime specifier [E0106]
<anon>:5 fn foo(n: int) -> &int {
                           ^~~~
<anon>:5:19: 5:23 help: this function's return type contains a borrowed value, but the signature does not say which one of `n`'s 0 elided lifetimes it is borrowed from
<anon>:5 fn foo(n: int) -> &int {
                           ^~~~
error: aborting due to previous error

[Tomaka17]

Il est pas cryptique ce message. Il te dit juste "missing lifetime specifier" avec un numéro que tu peux passer pour avoir plus d'infos : "rustc --explain E0106" (bon celui-là n'est pas encore implémenté).
La seconde ligne est simplement un "help", ça ne se voit pas bien vu qu'il n'y a pas les couleurs.

Après c'est sûr qu'un débutant qui ne sait pas ce qu'est un lifetime specifier il est pas aidé, mais c'est pas le compilateur qui va corriger ton code à ta place.

[Tramb]

Non, c'est de la merde.
Plus précisément le mec a un gros biais dès le départ et quasiment aucun des exemple pris n'est "fair", et encore moins l'analyse qu'il en fait.

Carrément d'accord, cette comparaison est ridicule.

Bon, pour les messages d'erreur, avouons qu'il a fallu des décennies aux compilos C++ pour avoir des messages d'erreurs d'instantiation de template faciles à lire (mais on y est).
Rust a le temps d'améliore sa 'Quality of Implementation" avec ça, il est jeune (et donc un peu crétin mais plein de bonne volonté pour l'instant).

[rOut]

Exactement ce que l'on reproche aux messages d'erreur sur des template.

In file included from /tmp/gcc-explorer-compiler1141115-14326-85vjpc/example.cpp:1:
In file included from /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/vector:60:
In file included from /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_algobase.h:71:
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/predefined_ops.h:191:17: error: invalid operands to binary expression ('std::vector<int, std::allocator<int> >' and 'int')
{ return *__it == _M_value; }
~~~~~ ^ ~~~~~~~~
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_algo.h:120:8: note: in instantiation of function template specialization '__gnu_cxx::__ops::_Iter_equals_val<const int>::operator()<__gnu_cxx::__normal_iterator<std::vector<int, std::allocator<int> > *, std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > > > >' requested here
if (__pred(__first))
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_algo.h:161:14: note: in instantiation of function template specialization 'std::__find_if<__gnu_cxx::__normal_iterator<std::vector<int, std::allocator<int> > *, std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > > >, __gnu_cxx::__ops::_Iter_equals_val<const int> >' requested here
return __find_if(__first, __last, __pred,
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_algo.h:3778:19: note: in instantiation of function template specialization 'std::__find_if<__gnu_cxx::__normal_iterator<std::vector<int, std::allocator<int> > *, std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > > >, __gnu_cxx::__ops::_Iter_equals_val<const int> >' requested here
return std::__find_if(__first, __last,
^
7 : note: in instantiation of function template specialization 'std::find<__gnu_cxx::__normal_iterator > *, std::vector >, std::allocator > > > >, int>' requested here
std::vector< std::vector <int> >::const_iterator it = std::find( v.begin(), v.end(), a );
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_pair.h:214:5: note: candidate template ignored: could not match 'pair' against 'vector'
operator==(const pair<_T1, _T2>& __x, const pair<_T1, _T2>& __y)
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_iterator.h:292:5: note: candidate template ignored: could not match 'reverse_iterator' against 'vector'
operator==(const reverse_iterator<_Iterator>& __x,
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_iterator.h:342:5: note: candidate template ignored: could not match 'reverse_iterator' against 'vector'
operator==(const reverse_iterator<_IteratorL>& __x,
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_iterator.h:808:5: note: candidate template ignored: could not match '__normal_iterator' against 'vector'
operator==(const __normal_iterator<_IteratorL, _Container>& __lhs,
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_iterator.h:815:5: note: candidate template ignored: could not match '__normal_iterator' against 'vector'
operator==(const __normal_iterator<_Iterator, _Container>& __lhs,
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_iterator.h:1048:5: note: candidate template ignored: could not match 'move_iterator' against 'vector'
operator==(const move_iterator<_IteratorL>& __x,
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_iterator.h:1054:5: note: candidate template ignored: could not match 'move_iterator' against 'vector'
operator==(const move_iterator<_Iterator>& __x,
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/ext/new_allocator.h:139:5: note: candidate template ignored: could not match 'new_allocator' against 'vector'
operator==(const new_allocator<_Tp>&, const new_allocator<_Tp>&)
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/allocator.h:128:5: note: candidate template ignored: could not match 'allocator' against 'vector'
operator==(const allocator<_T1>&, const allocator<_T2>&)
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/allocator.h:133:5: note: candidate template ignored: could not match 'allocator' against 'vector'
operator==(const allocator<_Tp>&, const allocator<_Tp>&)
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/stl_vector.h:1511:5: note: candidate template ignored: could not match 'vector<type-parameter-0-0, type-parameter-0-1>' against 'const int'
operator==(const vector<_Tp, _Alloc>& __x, const vector<_Tp, _Alloc>& __y)
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/postypes.h:216:5: note: candidate template ignored: could not match 'fpos' against 'vector'
operator==(const fpos<_StateT>& __lhs, const fpos<_StateT>& __rhs)
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/basic_string.h:2505:5: note: candidate template ignored: could not match 'basic_string' against 'vector'
operator==(const basic_string<_CharT, _Traits, _Alloc>& __lhs,
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/basic_string.h:2512:5: note: candidate template ignored: could not match 'basic_string' against 'vector'
operator==(const basic_string<_CharT>& __lhs,
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/basic_string.h:2526:5: note: candidate template ignored: could not match 'const _CharT *' against 'std::vector<int, std::allocator<int> >'
operator==(const _CharT* __lhs,
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/basic_string.h:2538:5: note: candidate template ignored: could not match 'basic_string' against 'vector'
operator==(const basic_string<_CharT, _Traits, _Alloc>& __lhs,
^
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/bits/random.tcc:2030:5: note: candidate template ignored: could not match 'normal_distribution' against 'vector'
operator==(const std::normal_distribution<_RealType>& __d1,
^
1 error generated.
Compilation failed

C'est pas cryptique, il te dit clairement qu'il ne trouve pas d'opérateur == qui prend un vector<int> et un int. error: invalid operands to binary expression ('std::vector<int, std::allocator<int> >' and 'int')

---------- Post added at 20h51 ---------- Previous post was at 20h49 ----------



---------- Post added at 20h52 ---------- Previous post was at 20h51 ----------

Carrément d'accord, cette comparaison est ridicule.

Bon, pour les messages d'erreur, avouons qu'il a fallu des décennies aux compilos C++ pour avoir des messages d'erreurs d'instantiation de template faciles à lire (mais on y est).
Rust a le temps d'améliore sa 'Quality of Implementation" avec ça, il est jeune (et donc un peu crétin mais plein de bonne volonté pour l'instant).

Non mais en plus même avec des exemples fair il aurait pu tirer une conclusion en faveur de Rust sans problème, mais là c'est juste n'importe quoi.

[Sp1d3r]

Je n'ai jamais rien vu de plus obscur que les messages d'erreur de compilation LaTeX.

[BentheXIII]

Je n'ai jamais rien vu de plus obscur que les messages d'erreur de compilation LaTeX.

Boaf. Avec un éditeur adapté (genre TexMaker) et sous réserve d'une structure de document pas compliquée, il te dit à quelle ligne ce que tu écris n'a plus aucun sens

Question noob pour rabaisser le débat: pourquoi est-il impossible de séparer déclaration et implémentation d'une fonction en C++ si le prototype de ladite fonction utilise un template?

[Sp1d3r]

Boaf. Avec un éditeur adapté (genre TexMaker) et sous réserve d'une structure de document pas compliqué, il te dit à quelle ligne ce que tu écris n'a plus aucun sens

Oui, en gros si tu as des include/input, ça marche plus. Il est incapable de se rendre qu'un bloc n'est pas fermé et va dire "memory error"... Et le message est tellement clair quand on a oublié d'échapper un "_", c'est magique. Au bout d'un moment on finit par toutes les connaître mais c'est lourd.

[BentheXIII]

Oui, en gros si tu as des include/input, ça marche plus. Il est incapable de se rendre qu'un bloc n'est pas fermé et va dire "memory error"... Et le message est tellement clair quand on a oublié d'échapper un "_", c'est magique. Au bout d'un moment on finit par toutes les connaître mais c'est lourd.

Vrais reconnaissent vrais. Le LaTeX dès la primaire pour tous !

[Tomaka17]

Question noob pour rabaisser le débat: pourquoi est-il impossible de séparer déclaration et implémentation d'une fonction en C++ si le prototype de ladite fonction utilise un template?

Quand tu as une classe normale (non-template), toutes les fonctions que tu écris se retrouvent dans ton exécutable final.
Par contre une classe template est, comme son nom l'indique, un template (un patron). Ce qui signifie que le code n'est créé qu'au moment où tu utilises la classe (autrement il faudrait générer du code pour toutes les combinaisons possibles). Par conséquent le compilateur doit avoir accès à l'ensemble du patron pour pouvoir faire cela.

Il y a une alternative cela dit, puisque tu peux écrire quelque chose comme "extern class MaClasse<int>; extern class MaClasse<bool>; etc." afin de dire explicitement au compilo pour quels paramètres template il doit générer le code (j'ai oublié la syntaxe exacte par contre, car je l'ai utilisée à peu près zéro fois). Si tu fais ça, tu peux mettre l'implémentation dans un fichier .cpp à part.

[BentheXIII]

Merci, ça me sera probablement utile par la suite!

[Orhin]

Je n'ai jamais rien vu de plus obscur que les messages d'erreur de compilation LaTeX.

Chuuut, y'en a qu'on des rapports en court de rédaction.

[Møgluglu]

Il y a une alternative cela dit, puisque tu peux écrire quelque chose comme "extern class MaClasse<int>; extern class MaClasse<bool>; etc." afin de dire explicitement au compilo pour quels paramètres template il doit générer le code (j'ai oublié la syntaxe exacte par contre, car je l'ai utilisée à peu près zéro fois). Si tu fais ça, tu peux mettre l'implémentation dans un fichier .cpp à part.

Oui, le mot-clef export, le truc qui n'est géré par quasiment aucun compilo.
À moins que ça n'ait changé récemment, mais j'ai l'impression que globalement tout le monde s'en fout.

[rOut]

http://en.cppreference.com/w/cpp/lan..._instantiation

La version extern sert à éviter que le compilateur instancie le template en question lors de la compilation du fichier ou il est présent, ça sert à lui dire "Stresse pas, je l'ai instancié ailleurs, t'auras toutes tes fonctions au link".

[Møgluglu]

OK, donc export est déprécié / supprimé en C++11 et remplacé par la syntaxe avec extern ?

Et il faut maintenant instancier explicitement chaque instanciation du template. C'est nettement plus simple pour le compilo, mais ça n'a plus vraiment d'intérêt... Si j'ai une classe vector<T> et que je ne veux pas me trimballer toute l'implèm dans les .h, je dois instancier dans mon vector.cpp tous les vector<int>, vector<Foo> et vector<Bar> utilisés quelque part dans le programme. Bravo la modularité.

[rOut]

Ben c'est pareil non ?

De toute manière il faut que tu ai la définition des fonctions instanciées quelque part.

[Møgluglu]

Non, si je dis pas de connerie avec export tu n'avais pas à spécifier les types instanciés. C'est d'ailleurs bien pour ça que c'était autant la merde : il fallait que le linker puisse rappeler le compilo pour instancier les templates en une deuxième passe (voire récursivement ?).
À côté, extern, c'est juste une modif triviale du parser.

[rOut]

Tu m'étonnes que personne ne l'ait implémenté.

[FB74]

Dites, ça vous parle ça ?

Licence gratuite pour outils de développement CppDepend, JArchitect, XClarify et VBDepend @ Codergears



C'est intéressant ?

[ook4mi]

Joyeux Noël à toutes et tous !

[Noospray]

Salut les canards,

Je cherche à remplacer le point par une virgule pour les float contenus dans une liste de type liste= [ ["a", 1.0], ["b", 2.75] ]

J'utilise ce petit bout de code :

    for row in ligne :
            row=str(row).replace('.',',')
            #print(row)
    print(ligne)

Or cela ne fonctionne pas.

Le print commenté affiche bien 1,0 ou 2,75, mais la ligne affichée à la fin est identique à celle du départ, soit [ ["a", 1.0], ["b", 2.75] ].

Je n'y comprend rien, surtout que l'exemple inverse : ligne = [['a', 1, 0], ['b', 2, 75]]

    for element in lignes :
        element=str(element)
        element.replace(',','.')

Me retourne bien [ ["a", 1.0], ["b", 2.75] ].

Pouvez-vous m'aider ?