Je ne mets pas en cause la qualité de la STL, qui est incontestement très bonne, mais son accessibilité pour un codeur C qui veut se mettre au C++ (ce qui est le cas ici).
Quand je dis que c'est "un sacré bordel", j'entends par là le coté assez ésotérique de la documentation, et non une éventuelle incohérence. Par ex:
issu de la doc de la stdc++ gnu (peut être s'agirait-il de la standard library et non de la standard template library? encore une subtilité pas évidente...) est pour moi assez imbitable, en tout cas bien plus que ce qu'on peut trouver dans la bibliothèque C standard. Il n'y a pas de doute que cette dernière est assez limitée mais elle reste efficace dans pas mal de cas, et en lui ajoutant la glib, on peut faire beaucoup de chose plus rapidement qu'en C++ (en comptant le temps d'apprentissage des subtilités de ce langage).
Pour les références, le problème n'est pas le principe mais la façon dont c'est implémenté en C++. Quand tu programmes en java, tu n'as pas de pointeurs, donc tu utilises forcement des références et tu n'as d'ailleurs pas à t'en soucier vu que la mémoire est gérée par le système grâce au garbage collector. Quand tu es en C++, tu dois jongler avec les variables dans la pile et dans le tas, les pointeurs et les références (le '&' pour les références n'aurait pas pu être plus mal choisi, bonjour la confusion avec le '&' "adresse de" et les 'et' logique et binaire), avec les types simples et complexes (tu passes une classe en argument, mais va tu passer un pointeur ou un bloc de 512 octet? tu fais une copie, mais va tu avoir une copie 'shallow', 'deep' ou 'copy-on-write'?) et ça n'est pas intuitif pour un codeur C. La doc du c++ le dit clairement : un référence est implémenté par un pointeur, mais celà doit être caché au programmeur. Je n'aime pas vraiment qu'un langage me cache des choses même si c'est pour mon bien. À chaque fois que j'utilise une chaîne en C++, je ne peux m'empécher de penser : mais va-t-elle être bien désallouée? (mauvaise habitude du C? peut être mais c'est ainsi...)
Ce sont effectivement des choses que l'on peut apprendre et qui deviennent très efficaces une fois maîtrisées, mais ça n'est pas évident lorsque l'on vient du C et que l'on a l'habitude de manipuler des types clairs. Le problème est que Stroustrup a voulu gardé la compatibilité entre le C et le C++, c'est l'un de ses avantage car ça a facilité sa propagation, mais c'est aussi l'un de ses inconveniants, car c'est devenu un langage syntaxiquement crade.
Enfin pour l'aspect objet (je répond aussi au msg dessous), on peut faire de l'objet avec n'importe quel langage, même assembleur. On profitera moins de la syntaxe qui guidera une architecture objet et des vérifications faites par le compilateur, mais ça n'a rien de particulièrement difficile, n'importe quel fichier C++ peut par exemple être entièrement traduit en C.
[^] # Re: Quel langage choisir ?
Posté par calandoa . En réponse au journal Quel langage choisir ?. Évalué à 1.
Quand je dis que c'est "un sacré bordel", j'entends par là le coté assez ésotérique de la documentation, et non une éventuelle incohérence. Par ex:
template<typename _CharT, typename _Traits>
basic_ostream< _CharT, _Traits > & std::basic_ostream< _CharT, _Traits >::operator<< ( __streambuf_type * __sb ) [inherited]
issu de la doc de la stdc++ gnu (peut être s'agirait-il de la standard library et non de la standard template library? encore une subtilité pas évidente...) est pour moi assez imbitable, en tout cas bien plus que ce qu'on peut trouver dans la bibliothèque C standard. Il n'y a pas de doute que cette dernière est assez limitée mais elle reste efficace dans pas mal de cas, et en lui ajoutant la glib, on peut faire beaucoup de chose plus rapidement qu'en C++ (en comptant le temps d'apprentissage des subtilités de ce langage).
Pour les références, le problème n'est pas le principe mais la façon dont c'est implémenté en C++. Quand tu programmes en java, tu n'as pas de pointeurs, donc tu utilises forcement des références et tu n'as d'ailleurs pas à t'en soucier vu que la mémoire est gérée par le système grâce au garbage collector. Quand tu es en C++, tu dois jongler avec les variables dans la pile et dans le tas, les pointeurs et les références (le '&' pour les références n'aurait pas pu être plus mal choisi, bonjour la confusion avec le '&' "adresse de" et les 'et' logique et binaire), avec les types simples et complexes (tu passes une classe en argument, mais va tu passer un pointeur ou un bloc de 512 octet? tu fais une copie, mais va tu avoir une copie 'shallow', 'deep' ou 'copy-on-write'?) et ça n'est pas intuitif pour un codeur C. La doc du c++ le dit clairement : un référence est implémenté par un pointeur, mais celà doit être caché au programmeur. Je n'aime pas vraiment qu'un langage me cache des choses même si c'est pour mon bien. À chaque fois que j'utilise une chaîne en C++, je ne peux m'empécher de penser : mais va-t-elle être bien désallouée? (mauvaise habitude du C? peut être mais c'est ainsi...)
Ce sont effectivement des choses que l'on peut apprendre et qui deviennent très efficaces une fois maîtrisées, mais ça n'est pas évident lorsque l'on vient du C et que l'on a l'habitude de manipuler des types clairs. Le problème est que Stroustrup a voulu gardé la compatibilité entre le C et le C++, c'est l'un de ses avantage car ça a facilité sa propagation, mais c'est aussi l'un de ses inconveniants, car c'est devenu un langage syntaxiquement crade.
Enfin pour l'aspect objet (je répond aussi au msg dessous), on peut faire de l'objet avec n'importe quel langage, même assembleur. On profitera moins de la syntaxe qui guidera une architecture objet et des vérifications faites par le compilateur, mais ça n'a rien de particulièrement difficile, n'importe quel fichier C++ peut par exemple être entièrement traduit en C.