Le C++ peut faire les deux, en fait (bas niveau, haut niveau). Après, gcc eux-mêmes utilisaient un garbage collector avant (j'avais vu un article sur lwn.net, qui expliquait qu'ils allaient intégrer du C++ pour réduire ça et donc améliorer les perfs, secoués par le succès alors montant de clang), et pourtant, c'est (c'était?) du C, donc bon...
On peut utiliser le C++ sans la STL, et dans ce cas on doit faire la gestion de la mémoire à la main (encore que, dans ce cas, on code soit-même ses wrappers...).
Parfois même, pas le choix, par exemple si on veut utiliser mmap (qui renvoie -1 et pas 0 en cas d'échec «On error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno is set to indicate the cause of the error.») ou, plus parlant compte tenu du journal: dans le cas d'openGL ou dans de vulkan (ça retourne des handles, donc std::unique_ptr peut pas gérer sans intermédiaire).
Mais bon, je suis d'accord que:
Et même dans des langages bas niveau tel que le C, ou haut niveau tel que le C++ ou le Go, ces choses sont masquées.
Est juste une affirmation fausse: en C, si, il y a une gestion de la mémoire: malloc/calloc/realloc/free, c'est plus simple à utiliser que maintenir soit-même le tas et la pile du programme.
Toujours à ma connaissance en C, il n'y a pas besoin d'empiler manuellement avant d'appeler une fonction, ni de faire l'inverse en en sortant.
Ce qu'il manque au C (selon moi) pour alléger considérablement la charge des développeurs, c'est un mécanisme à la defer (go, je crois?).
Toujours en parlant de jeu vidéo, l'auteur devrais s'amuser un peu avec le langage de script de mindustry, la, il verrait ce qu'est une absence de gestion de la mémoire.
Et toujours à ma connaissance, en C++ les automatismes de gestion de la mémoire, ça se limite à la STL (mais je doute que Rust n'ait pas une lib pour tableaux dynamiques, listes chaînées, dictionnaires, ... hein) ainsi qu'à la RAII (idem, je doute que Rust ne permette pas ce genre de choses, d'une façon ou d'une autre).
Comme je l'ai dit plus haut, la STL elle-même n'est pas parfaite, mais c'est bien assez bon dans 99% des cas.
Je me demande a quoi sert cette phrase en fait. Pourquoi dénigrer les autres langages (surtout en intro, ça ne donne pas envie)? Rust n'a-t-il donc pas assez de qualités?
[^] # Re: C++, haut niveau ?
Posté par freem . En réponse au journal Écrire un jeu en Rust presque de zéro. Évalué à 7.
Le C++ peut faire les deux, en fait (bas niveau, haut niveau). Après, gcc eux-mêmes utilisaient un garbage collector avant (j'avais vu un article sur lwn.net, qui expliquait qu'ils allaient intégrer du C++ pour réduire ça et donc améliorer les perfs, secoués par le succès alors montant de clang), et pourtant, c'est (c'était?) du C, donc bon...
On peut utiliser le C++ sans la STL, et dans ce cas on doit faire la gestion de la mémoire à la main (encore que, dans ce cas, on code soit-même ses wrappers...).
Parfois même, pas le choix, par exemple si on veut utiliser mmap (qui renvoie -1 et pas 0 en cas d'échec «On error, the value MAP_FAILED (that is, (void *) -1) is returned, and errno is set to indicate the cause of the error.») ou, plus parlant compte tenu du journal: dans le cas d'openGL ou dans de vulkan (ça retourne des handles, donc std::unique_ptr peut pas gérer sans intermédiaire).
Mais bon, je suis d'accord que:
Est juste une affirmation fausse: en C, si, il y a une gestion de la mémoire: malloc/calloc/realloc/free, c'est plus simple à utiliser que maintenir soit-même le tas et la pile du programme.
Toujours à ma connaissance en C, il n'y a pas besoin d'empiler manuellement avant d'appeler une fonction, ni de faire l'inverse en en sortant.
Ce qu'il manque au C (selon moi) pour alléger considérablement la charge des développeurs, c'est un mécanisme à la
defer(go, je crois?).Toujours en parlant de jeu vidéo, l'auteur devrais s'amuser un peu avec le langage de script de mindustry, la, il verrait ce qu'est une absence de gestion de la mémoire.
Et toujours à ma connaissance, en C++ les automatismes de gestion de la mémoire, ça se limite à la STL (mais je doute que Rust n'ait pas une lib pour tableaux dynamiques, listes chaînées, dictionnaires, ... hein) ainsi qu'à la RAII (idem, je doute que Rust ne permette pas ce genre de choses, d'une façon ou d'une autre).
Comme je l'ai dit plus haut, la STL elle-même n'est pas parfaite, mais c'est bien assez bon dans 99% des cas.
Je me demande a quoi sert cette phrase en fait. Pourquoi dénigrer les autres langages (surtout en intro, ça ne donne pas envie)? Rust n'a-t-il donc pas assez de qualités?