Je voulais parler des messages d'erreurs, mais je ne me suis rendu compte de l'ambiguïté après avoir validé.
Ça c'est partout pareil (à part les templates encore une fois) ; quand on a l'habitude du langage, les messages sont clairs, quand on n'en a pas l'habitude, on galère et on cherche.
Par contre, je rebondis sur la prétendue facilité : quand définir un membre statique (encore un exemple de syntaxe absconse d'ailleurs) au mauvais endroit fait segfault le programme totalement ailleurs, ce n'est pas facile d'écrire du code sans segfault.
C'est quoi le mauvais endroit ? J'ai jamais eu de soucis, mais peut-être ai-je les bonnes pratiques ?
Par ailleurs, il y a plein de facilités pour écrire du code qui segfault (arithmétique des pointeurs, casts à l'arrache, padding des structs, pas de garantie de la durée de vie des objets, ...).
Même propos qu'avant : c'est pas parce que c'est là, qu'on doit utilise. Si on comprend pas, n'utilise pas, n'a pas besoin, alors pourquoi y jeter un oeil ?
Ça veut dire quoi « pas de garantie de la durée de vie des objets » ?
Il devrait simplement disparaître. Les #include c'était bien en 1960
Même topo : en cas c'est gênant ; il suffit de pas utiliser.
Non, parce que l'ABI des smart pointers n'est pas définie ; donc l'interopérabilité du code n'est garantie que pour des libs headers-only.
Encore une fois, il s'agit d'un choix de librairies.
Récupérer boost en dépendance pour pouvoir gérer le FS correctement, c'est tout de même un peu fort
et
pas d'accord car c'est surtout une manière de coder
Non question de philosophie de langage.
Pour ton problème de suppression de case (vient de SO):
vec.erase(std::remove(vec.begin(), vec.end(), int_to_remove), vec.end());
Un tableau n'est pas une liste, il est logique qu'il faille un certain nombre de manipulation pour retirer une case. Après si on désire faire des choses plus facilement, pourquoi pas la QList ? C'est à dire utiliser d'autres librairies.
Parce que ça implique de maintenir plein de choses dans le langage juste pour conserver cette compatibilité, ce qui freine l'évolution du standard.
Franchement ça me concerne pas en tant que développeur.
Pour la suite je ne parle pas particulièrement de toi.
Quand je vois la teneur des reproches (car je sens plus de la colère qu'autre chose, et on voit les notes dès que l'on soutient le C++), je pense que c'est surtout idéologique.
En gros on reproche :
- des trucs trop compliqués à utiliser, et que l'on se force à utiliser
- des trucs pas nécessaires et qu'on a pas à utiliser, et que l'on se force à utiliser
- le fait d'avoir à utiliser des librairies (on verra dans quelques temps les « Go, Rust, Swift, Elixir, Nim » quand ils commenceront à avoir des librairies à gauche et à droite, qu'il y aura les problèmes de versionement, etc ; pensez à python, javascript qui étaient vachement mieux que tout).
- c'est lent à compiler ; les entêtes pré-compilés ?
- les templates : ok, on sait, tout le monde le sait, le dit, le pense
Non vraiment il y a des trucs chiants en C++ (ok il y a les TEMPLATES, et beaucoup d'autres choses qui bizarrement n'apparaissent pas), mais personne n'oblige personne à utiliser quoique ce soit.
[^] # Re: Donc pour résumer...
Posté par lem__mel . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à -2.
Ça c'est partout pareil (à part les templates encore une fois) ; quand on a l'habitude du langage, les messages sont clairs, quand on n'en a pas l'habitude, on galère et on cherche.
C'est quoi le mauvais endroit ? J'ai jamais eu de soucis, mais peut-être ai-je les bonnes pratiques ?
Même propos qu'avant : c'est pas parce que c'est là, qu'on doit utilise. Si on comprend pas, n'utilise pas, n'a pas besoin, alors pourquoi y jeter un oeil ?
Ça veut dire quoi « pas de garantie de la durée de vie des objets » ?
Même topo : en cas c'est gênant ; il suffit de pas utiliser.
Encore une fois, il s'agit d'un choix de librairies.
Non question de philosophie de langage.
Pour ton problème de suppression de case (vient de SO):
vec.erase(std::remove(vec.begin(), vec.end(), int_to_remove), vec.end());
Un tableau n'est pas une liste, il est logique qu'il faille un certain nombre de manipulation pour retirer une case. Après si on désire faire des choses plus facilement, pourquoi pas la QList ? C'est à dire utiliser d'autres librairies.
Franchement ça me concerne pas en tant que développeur.
Pour la suite je ne parle pas particulièrement de toi.
Quand je vois la teneur des reproches (car je sens plus de la colère qu'autre chose, et on voit les notes dès que l'on soutient le C++), je pense que c'est surtout idéologique.
En gros on reproche :
- des trucs trop compliqués à utiliser, et que l'on se force à utiliser
- des trucs pas nécessaires et qu'on a pas à utiliser, et que l'on se force à utiliser
- le fait d'avoir à utiliser des librairies (on verra dans quelques temps les « Go, Rust, Swift, Elixir, Nim » quand ils commenceront à avoir des librairies à gauche et à droite, qu'il y aura les problèmes de versionement, etc ; pensez à python, javascript qui étaient vachement mieux que tout).
- c'est lent à compiler ; les entêtes pré-compilés ?
- les templates : ok, on sait, tout le monde le sait, le dit, le pense
Non vraiment il y a des trucs chiants en C++ (ok il y a les TEMPLATES, et beaucoup d'autres choses qui bizarrement n'apparaissent pas), mais personne n'oblige personne à utiliser quoique ce soit.