Réseau CPC BIENDEBUTER.NET Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
+ Reply to Thread
Page 217 of 217 FirstFirst ... 117 167 207 209 210 211 212 213 214 215 216 217
Results 6,481 to 6,507 of 6507
  1. #6481
    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)
    Rust fanboy

  2. #6482
    Et le PHP dans tout ça ?

    Quote Originally Posted by TiNitro View Post
    @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.

  3. #6483
    Quote Originally Posted by Tomaka17 View Post
    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.

  4. #6484
    Quote Originally Posted by fougny View Post
    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.
    Rust fanboy

  5. #6485
    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.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution." · 6hit combo!

  6. #6486
    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.

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

  8. #6488
    Je ne sais pas si on peut faire une distinction claire, mais à mon avis ça reste des bugs techniques, pas des bugs de logique.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution." · 6hit combo!

  9. #6489
    Quote Originally Posted by fougny View Post
    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.
    It's the moped lads, they like to think they're bad
    It's the moped lads, if you hit 'em they'll tell their dads

  10. #6490

  11. #6491
    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

    Code:
    <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
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution." · 6hit combo!

  12. #6492
    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.
    Rust fanboy

  13. #6493
    Quote Originally Posted by rOut View Post
    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).
    It's the moped lads, they like to think they're bad
    It's the moped lads, if you hit 'em they'll tell their dads

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

    Code:
    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 ----------

    Quote Originally Posted by Tramb View Post
    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.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution." · 6hit combo!

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

  16. #6496
    Quote Originally Posted by Sp1d3r View Post
    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?
    Quote Originally Posted by Colargol View Post
    Mais globalement l'ingenieur en France il bosse un peu a l'africaine: ca marche mais ca fait pas serieux

  17. #6497
    Quote Originally Posted by BentheXIII View Post
    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.

  18. #6498
    Quote Originally Posted by Sp1d3r View Post
    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 !
    Quote Originally Posted by Colargol View Post
    Mais globalement l'ingenieur en France il bosse un peu a l'africaine: ca marche mais ca fait pas serieux

  19. #6499
    Quote Originally Posted by BentheXIII View Post
    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.
    Rust fanboy

  20. #6500
    Merci, ça me sera probablement utile par la suite!
    Quote Originally Posted by Colargol View Post
    Mais globalement l'ingenieur en France il bosse un peu a l'africaine: ca marche mais ca fait pas serieux

  21. #6501
    Quote Originally Posted by Sp1d3r View Post
    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.

  22. #6502
    Quote Originally Posted by Tomaka17 View Post
    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.

  23. #6503
    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".
    Last edited by rOut; 16/12/2014 at 17h18.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution." · 6hit combo!

  24. #6504
    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é.

  25. #6505
    Ben c'est pareil non ?

    De toute manière il faut que tu ai la définition des fonctions instanciées quelque part.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution." · 6hit combo!

  26. #6506
    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.

  27. #6507
    Tu m'étonnes que personne ne l'ait implémenté.
    "Dieu est mort" · "Si le téléchargement c’est du vol, Linux c’est de la prostitution." · 6hit combo!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts