j'ai quelque expérience en C++ et avec les templates mais n'ai jamais
utilisé la STL et, ayant un projet en vue, je m'interresse à l'intérêt que
peux m'apporter cette bibliothèque. J'ai donc récupéré une implémentation
libre de cette dernière afin de comprendre ce qui se passait en coulisse. Il
m'est alors venu une série de questions que je vous soumets :
j'ai tout d'abord inspecté rapidement le modèle "vector" : corrigez moi si
je me trompe.
il semble que l'ajout (push_back) d'un objet provoque une réallocation de
l'ensemble du tableau. Dispendieux au niveau temps ?
il est possible de réserver à l'avance un espace pour eviter cet
inconvénient, mais la aussi cela implique d'initialiser cet espace (encore
dispendieux).
je pense alors que pour avoir des conteneurs efficaces, il est nécessaire au
moins de dériver ces conteneurs de base.
Mais la aussi je me heurte à quelques problèmes : supposons tout simplement
que je veuille créer un conteneur tableau trié d'objets (et qui le restent
lors d'ajouts).
une insertion efficace se fait via une recherche dichotomique : j'ai trouvé
binary_search mais celui ci ne renvoie pas d'iterateur (?). la methode
"find" quant à elle ne peut pas faire une recherche dichotomique étant donné
que le tableau n'est pas sensé être trié (??)
j'ai entendu dire également que cette bibliothèque était "thread-safe" or je
n'ai vu aucun code de synchronisation dans le source de la bibliothèque
récupéré (??)
je me suis posé également la question de création de conteneurs indirects
par ex un conteneur de pointeurs d'objets : lors de la suppression par
"erase", la suppression ne doit effacer que le pointeur et non l'objet sur
lequel il pointe, d'ou la neccessité de créer une fonction dérivée afin de
réaliser les choses correctement, n'est-ce pas ?
bref je me pose la question de l'utilité de cette bibliothèque dans le cadre
d'un développement dont le temps de traitement est un facteur déterminant.
merci de vos éclaircissements et de me faire partager votre expérience sur
cette bibliothèque.
On Wed, 10 Jun 2009 12:31:30 +0200, (Pascal J. Bourguignon):
approche plus fonctionnelle que procédurale
T'as essayé Haskell ?
En effet, je n'utilise pas C++ si on ne me paye pas pour...
-- __Pascal Bourguignon__
pjb
Gabriel Dos Reis writes:
(Pascal J. Bourguignon) writes:
[...]
| Alors il n'y a pas de raison de supposer que la STL ne fasse pas | partie des choses à éviter, au moins dans certains contextes.
Bonne chance.
| Honêtement, jusqu'à ce qu'un client me demande d'utiliser la STL, dans | tous mes développement C++, je ne l'ai jamais utilisé (d'abord, elle | n'existait pas, ensuite j'avais développé ma propre bibliothèque). De | nos jours, si je voulais réaliser un développement en C++, je | n'utiliserais pas la STL, mais je développerais aussi ma propre | bibliothèque, sur d'autre fondements que ceux de la STL ou de | boost. (eg. pas de smart pointeur, mais un vrai garbage collecteur, une | approche plus fonctionnelle que procédurale, etc).
Pourquoi tu n'écris pas directement du Lisp ? Quelqu'un m'a dit que c'est vachement mieux et plus haut niveau que le C++.
Exactement. Ayant à ma disposition des implémentations Common Lisp, l'hypothèse n'est pas remplie, et donc l'usage du conditionnel s'imposait bien dans le conséquent.
-- __Pascal Bourguignon__
Gabriel Dos Reis <gdr@cse.tamu.edu> writes:
pjb@informatimago.com (Pascal J. Bourguignon) writes:
[...]
| Alors il n'y a pas de raison de supposer que la STL ne fasse pas
| partie des choses à éviter, au moins dans certains contextes.
Bonne chance.
| Honêtement, jusqu'à ce qu'un client me demande d'utiliser la STL, dans
| tous mes développement C++, je ne l'ai jamais utilisé (d'abord, elle
| n'existait pas, ensuite j'avais développé ma propre bibliothèque). De
| nos jours, si je voulais réaliser un développement en C++, je
| n'utiliserais pas la STL, mais je développerais aussi ma propre
| bibliothèque, sur d'autre fondements que ceux de la STL ou de
| boost. (eg. pas de smart pointeur, mais un vrai garbage collecteur, une
| approche plus fonctionnelle que procédurale, etc).
Pourquoi tu n'écris pas directement du Lisp ? Quelqu'un m'a dit que
c'est vachement mieux et plus haut niveau que le C++.
Exactement. Ayant à ma disposition des implémentations Common Lisp,
l'hypothèse n'est pas remplie, et donc l'usage du conditionnel
s'imposait bien dans le conséquent.
| Alors il n'y a pas de raison de supposer que la STL ne fasse pas | partie des choses à éviter, au moins dans certains contextes.
Bonne chance.
| Honêtement, jusqu'à ce qu'un client me demande d'utiliser la STL, dans | tous mes développement C++, je ne l'ai jamais utilisé (d'abord, elle | n'existait pas, ensuite j'avais développé ma propre bibliothèque). De | nos jours, si je voulais réaliser un développement en C++, je | n'utiliserais pas la STL, mais je développerais aussi ma propre | bibliothèque, sur d'autre fondements que ceux de la STL ou de | boost. (eg. pas de smart pointeur, mais un vrai garbage collecteur, une | approche plus fonctionnelle que procédurale, etc).
Pourquoi tu n'écris pas directement du Lisp ? Quelqu'un m'a dit que c'est vachement mieux et plus haut niveau que le C++.
Exactement. Ayant à ma disposition des implémentations Common Lisp, l'hypothèse n'est pas remplie, et donc l'usage du conditionnel s'imposait bien dans le conséquent.
-- __Pascal Bourguignon__
Fabien LE LEZ
On Wed, 10 Jun 2009 14:28:34 +0200, (Pascal J. Bourguignon):
Ayant à ma disposition des implémentations Common Lisp, l'hypothèse n'est pas remplie, et donc l'usage du conditionnel s'imposait bien dans le conséquent.
Si j'ai bien compris, tu ne programmes pas en C++ moderne, et tu n'as pas l'expérience de la STL.
On Wed, 10 Jun 2009 14:28:34 +0200, pjb@informatimago.com (Pascal J.
Bourguignon):
Ayant à ma disposition des implémentations Common Lisp,
l'hypothèse n'est pas remplie, et donc l'usage du conditionnel
s'imposait bien dans le conséquent.
Si j'ai bien compris, tu ne programmes pas en C++ moderne, et tu n'as
pas l'expérience de la STL.
On Wed, 10 Jun 2009 14:28:34 +0200, (Pascal J. Bourguignon):
Ayant à ma disposition des implémentations Common Lisp, l'hypothèse n'est pas remplie, et donc l'usage du conditionnel s'imposait bien dans le conséquent.
Si j'ai bien compris, tu ne programmes pas en C++ moderne, et tu n'as pas l'expérience de la STL.
pjb
Fabien LE LEZ writes:
On Wed, 10 Jun 2009 14:28:34 +0200, (Pascal J. Bourguignon):
Ayant à ma disposition des implémentations Common Lisp, l'hypothèse n'est pas remplie, et donc l'usage du conditionnel s'imposait bien dans le conséquent.
Si j'ai bien compris, tu ne programmes pas en C++ moderne, et tu n'as pas l'expérience de la STL.
Si, au contraire. Il faut distinguer l'usage "professionnel", payé par des clients qui imposent l'usage de la STL, de l'usage "personnel", où on peut choisir les outils les plus efficaces.
-- __Pascal Bourguignon__
Fabien LE LEZ <gramster@gramster.com> writes:
On Wed, 10 Jun 2009 14:28:34 +0200, pjb@informatimago.com (Pascal J.
Bourguignon):
Ayant à ma disposition des implémentations Common Lisp,
l'hypothèse n'est pas remplie, et donc l'usage du conditionnel
s'imposait bien dans le conséquent.
Si j'ai bien compris, tu ne programmes pas en C++ moderne, et tu n'as
pas l'expérience de la STL.
Si, au contraire. Il faut distinguer l'usage "professionnel", payé par
des clients qui imposent l'usage de la STL, de l'usage "personnel",
où on peut choisir les outils les plus efficaces.
On Wed, 10 Jun 2009 14:28:34 +0200, (Pascal J. Bourguignon):
Ayant à ma disposition des implémentations Common Lisp, l'hypothèse n'est pas remplie, et donc l'usage du conditionnel s'imposait bien dans le conséquent.
Si j'ai bien compris, tu ne programmes pas en C++ moderne, et tu n'as pas l'expérience de la STL.
Si, au contraire. Il faut distinguer l'usage "professionnel", payé par des clients qui imposent l'usage de la STL, de l'usage "personnel", où on peut choisir les outils les plus efficaces.
-- __Pascal Bourguignon__
espie
In article , Pascal J. Bourguignon wrote:
Honêtement, jusqu'à ce qu'un client me demande d'utiliser la STL, dans tous mes développement C++, je ne l'ai jamais utilisé (d'abord, elle n'existait pas, ensuite j'avais développé ma propre bibliothèque). De nos jours, si je voulais réaliser un développement en C++, je n'utiliserais pas la STL, mais je développerais aussi ma propre bibliothèque, sur d'autre fondements que ceux de la STL ou de boost. (eg. pas de smart pointeur, mais un vrai garbage collecteur, une approche plus fonctionnelle que procédurale, etc).
Bref, tu fais du lisp en C++, et en n'importe quoi d'autre...
(si tout ce que vous avez dans votre boite a outils est un marteau, c'est fou comme tout se met a ressembler a des clous).
C'est un point de vue qui a conduit a ces aberrations cote maintainabilite et performances que sont gcc, emacs, et autoconf.
(on observe que tout projet gnu suffisamment ancien se met a embarquer un interpreteur lisp, avec tous les problemes de typage et d'efficacite qui vont avec...)
In article <7cmy8g4by5.fsf@pbourguignon.anevia.com>,
Pascal J. Bourguignon <pjb@informatimago.com> wrote:
Honêtement, jusqu'à ce qu'un client me demande d'utiliser la STL, dans
tous mes développement C++, je ne l'ai jamais utilisé (d'abord, elle
n'existait pas, ensuite j'avais développé ma propre bibliothèque). De
nos jours, si je voulais réaliser un développement en C++, je
n'utiliserais pas la STL, mais je développerais aussi ma propre
bibliothèque, sur d'autre fondements que ceux de la STL ou de
boost. (eg. pas de smart pointeur, mais un vrai garbage collecteur, une
approche plus fonctionnelle que procédurale, etc).
Bref, tu fais du lisp en C++, et en n'importe quoi d'autre...
(si tout ce que vous avez dans votre boite a outils est un marteau, c'est
fou comme tout se met a ressembler a des clous).
C'est un point de vue qui a conduit a ces aberrations cote maintainabilite
et performances que sont gcc, emacs, et autoconf.
(on observe que tout projet gnu suffisamment ancien se met a embarquer
un interpreteur lisp, avec tous les problemes de typage et d'efficacite
qui vont avec...)
Honêtement, jusqu'à ce qu'un client me demande d'utiliser la STL, dans tous mes développement C++, je ne l'ai jamais utilisé (d'abord, elle n'existait pas, ensuite j'avais développé ma propre bibliothèque). De nos jours, si je voulais réaliser un développement en C++, je n'utiliserais pas la STL, mais je développerais aussi ma propre bibliothèque, sur d'autre fondements que ceux de la STL ou de boost. (eg. pas de smart pointeur, mais un vrai garbage collecteur, une approche plus fonctionnelle que procédurale, etc).
Bref, tu fais du lisp en C++, et en n'importe quoi d'autre...
(si tout ce que vous avez dans votre boite a outils est un marteau, c'est fou comme tout se met a ressembler a des clous).
C'est un point de vue qui a conduit a ces aberrations cote maintainabilite et performances que sont gcc, emacs, et autoconf.
(on observe que tout projet gnu suffisamment ancien se met a embarquer un interpreteur lisp, avec tous les problemes de typage et d'efficacite qui vont avec...)
Richard Delorme
Marc Espie a écrit :
(si tout ce que vous avez dans votre boite a outils est un marteau, c'est fou comme tout se met a ressembler a des clous).
