si tu es amené à coder toi-même ton propre conteneur, c'est aussi peut-être que tu es en train de faire quelque chose de compliqué
Hum... il suffit d'avoir besoin de performances ou de fiabilité. Avec la STL, il n'existe aucun moyen simple de diagnostiquer l'usage mémoire, ce qui implique qu'on n'est jamais trop sûrs quand le conteneur va nécessiter une réallocation et donc pourrir les itérateurs ou tout simplement que l'on ne peut savoir combien de mémoire une collection consomme (amuses-toi à calculer la RAM bouffée par une map...).
Sinon, la STL n'implémente aucun conteneur pour gérer les chaînes de caractères: std::string se contente de gérer des chaînes d'octets supposément caractères ASCII, ou éventuellement des wchar.
Il n'y a aucun ring buffer non plus.
Les tableaux associatifs sont habituellement implémentés en tant que RBTree, consommateurs en mémoire (une chiée de pointeurs sur 8 octets, donc de très probables cache miss en cascade).
Pas moyen de gérer une destruction automatique de ressource qui ne soit pas de la RAM. Pas moyen de gérer la destruction de RAM allouée par une lib utilisant le modèle hourglass sans overhead (hourglass: passer par une API «simple» sans exceptions ni RTTI pour facilité la stabilité d'ABI, par exemple pour un mécanisme de plugins).
Mais bon, je suis d'accord, tant qu'on veut juste faire la fonctionnalité en prototype, la STL dispose de tout ce qu'il faut.
J'ai même l'impression que la philosophie de la POO se perd complètement quand on adopte des pratiques basées sur les templates.
Pour moi, les deux approches sont complémentaires. Tu cites les conteneurs standards, et justement ils montrent la complémentarité: sans eux, en C++, on serait obligé de soit réimplémenter les conteneurs pour chaque type, soit les implémenter une seule fois et que chaque noeud prenne un void* et un void_free( void* ). Outre le problème de la RAM, il y a le problème de la type safety donc.
Quand je code en C++, j'utilise des classes, de l'héritage, des templates, des fonctions... en fonction de ce dont j'ai (supposément) vraiment besoin.
[^] # Re: Namespace bits ?
Posté par freem . En réponse au journal Jouons avec le ``switch`` et C++17. Évalué à 5.
Hum... il suffit d'avoir besoin de performances ou de fiabilité. Avec la STL, il n'existe aucun moyen simple de diagnostiquer l'usage mémoire, ce qui implique qu'on n'est jamais trop sûrs quand le conteneur va nécessiter une réallocation et donc pourrir les itérateurs ou tout simplement que l'on ne peut savoir combien de mémoire une collection consomme (amuses-toi à calculer la RAM bouffée par une map...).
Sinon, la STL n'implémente aucun conteneur pour gérer les chaînes de caractères: std::string se contente de gérer des chaînes d'octets supposément caractères ASCII, ou éventuellement des wchar.
Il n'y a aucun ring buffer non plus.
Les tableaux associatifs sont habituellement implémentés en tant que RBTree, consommateurs en mémoire (une chiée de pointeurs sur 8 octets, donc de très probables cache miss en cascade).
Pas moyen de gérer une destruction automatique de ressource qui ne soit pas de la RAM. Pas moyen de gérer la destruction de RAM allouée par une lib utilisant le modèle hourglass sans overhead (hourglass: passer par une API «simple» sans exceptions ni RTTI pour facilité la stabilité d'ABI, par exemple pour un mécanisme de plugins).
Mais bon, je suis d'accord, tant qu'on veut juste faire la fonctionnalité en prototype, la STL dispose de tout ce qu'il faut.
Pour moi, les deux approches sont complémentaires. Tu cites les conteneurs standards, et justement ils montrent la complémentarité: sans eux, en C++, on serait obligé de soit réimplémenter les conteneurs pour chaque type, soit les implémenter une seule fois et que chaque noeud prenne un void* et un void_free( void* ). Outre le problème de la RAM, il y a le problème de la type safety donc.
Quand je code en C++, j'utilise des classes, de l'héritage, des templates, des fonctions... en fonction de ce dont j'ai (supposément) vraiment besoin.