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.
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...)
Greenspun's Tenth Rule of Programming: âAny sufficiently complicate d C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.â
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...)
Greenspun's Tenth Rule of Programming: âAny sufficiently complicate d C
or Fortran program contains an ad-hoc, informally-specified bug-ridden
slow implementation of half of Common Lisp.â
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...)
Greenspun's Tenth Rule of Programming: âAny sufficiently complicate d C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.â
où la dimension est automatiquement déduite, tu aurais pu faire une proposition lors du commentaire pour le dernier CD.
Je crois que ça aurait été un peu tard pour proposer une nouvelle fonctionalité, mais oui, j'aurais pû le proposer plus tôt. Seulement, écrire une proposition valable, c'est pas mal de travail, et dans ce cas précis, l'array de C fait suffisamment bien l'affaire ; au moins dans mon code, de tels arrays ont toujours une portée assez limitée, de façon que les problèmes connus des arrays de type C n'interviennent pas.
(Je crois qu'il est encore possible de faire quelque chose comme ça par l'intermédiaire de l'AFNOR).
Dans tous les cas, je crois qu'on a plus de raisons de se plaindre quand on a fait une proposition concrète dans le sens (et qu'elle a été rejettée) que se plaindre sans avoir proposé des solutions aux défauts perçus.
Je ne me plaignais pas vraiment. Je notais simplement qu'il y a encore un cas où les arrays de type C n'ont pas de remplaçant. Un langage n'est jamais parfait, et dans ce cas, l'état actuel est « good enough », même s'il n'est pas parfait de point de vue théorique.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jun 10, 12:12 pm, Gabriel Dos Reis <g...@cse.tamu.edu> wrote:
James Kanze <james.ka...@gmail.com> writes:
| On Jun 9, 12:22 pm, Michael Doubez <michael.dou...@free.fr>
wrote:>> On 9 juin, 11:22, p...@informatimago.com (Pascal J.
Bourguignon)
>> wrote:
>> La seule chose qu'on peut regretter, c'est les statut des
>> tableaux (mais on peut utiliser std::tr1::array a la
>> place).
| Qui devient std::array dans la prochaine version de la norme.
| Mais qui ne permet toujours pas de choses comme:
où la dimension est automatiquement déduite, tu aurais pu
faire une proposition lors du commentaire pour le dernier CD.
Je crois que ça aurait été un peu tard pour proposer une
nouvelle fonctionalité, mais oui, j'aurais pû le proposer plus
tôt. Seulement, écrire une proposition valable, c'est pas mal de
travail, et dans ce cas précis, l'array de C fait suffisamment
bien l'affaire ; au moins dans mon code, de tels arrays ont
toujours une portée assez limitée, de façon que les problèmes
connus des arrays de type C n'interviennent pas.
(Je crois qu'il est encore possible de faire quelque chose
comme ça par l'intermédiaire de l'AFNOR).
Dans tous les cas, je crois qu'on a plus de raisons de se
plaindre quand on a fait une proposition concrète dans le sens
(et qu'elle a été rejettée) que se plaindre sans avoir proposé
des solutions aux défauts perçus.
Je ne me plaignais pas vraiment. Je notais simplement qu'il y a
encore un cas où les arrays de type C n'ont pas de remplaçant.
Un langage n'est jamais parfait, et dans ce cas, l'état actuel
est « good enough », même s'il n'est pas parfait de point de vue
théorique.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
où la dimension est automatiquement déduite, tu aurais pu faire une proposition lors du commentaire pour le dernier CD.
Je crois que ça aurait été un peu tard pour proposer une nouvelle fonctionalité, mais oui, j'aurais pû le proposer plus tôt. Seulement, écrire une proposition valable, c'est pas mal de travail, et dans ce cas précis, l'array de C fait suffisamment bien l'affaire ; au moins dans mon code, de tels arrays ont toujours une portée assez limitée, de façon que les problèmes connus des arrays de type C n'interviennent pas.
(Je crois qu'il est encore possible de faire quelque chose comme ça par l'intermédiaire de l'AFNOR).
Dans tous les cas, je crois qu'on a plus de raisons de se plaindre quand on a fait une proposition concrète dans le sens (et qu'elle a été rejettée) que se plaindre sans avoir proposé des solutions aux défauts perçus.
Je ne me plaignais pas vraiment. Je notais simplement qu'il y a encore un cas où les arrays de type C n'ont pas de remplaçant. Un langage n'est jamais parfait, et dans ce cas, l'état actuel est « good enough », même s'il n'est pas parfait de point de vue théorique.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
On Jun 10, 12:31 pm, (Pascal J. Bourguignon) wrote:
Gabriel Dos Reis writes:
[...]
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).
Ce qui présentera un autre jeu de problèmes : si tu dois le développer, c'est un travail important, supplémentaire, et même si tu l'as déjà sous la main, c'est un travail supplémentaire pour chacun qui lit ton code de l'apprendre. Moi aussi, je trouve que ma bibliothèque pré-standard était supérieur à la STL. Mais sauf dans les cas spéciaux, où il implémente quelque chose qui n'a réelement pas d'équivalent dans la STL, j'utilise la bibliothèque standard. Par considération à ceux qui vont lire mon code.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jun 10, 12:31 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
Gabriel Dos Reis <g...@cse.tamu.edu> writes:
[...]
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).
Ce qui présentera un autre jeu de problèmes : si tu dois le
développer, c'est un travail important, supplémentaire, et même
si tu l'as déjà sous la main, c'est un travail supplémentaire
pour chacun qui lit ton code de l'apprendre. Moi aussi, je
trouve que ma bibliothèque pré-standard était supérieur à la
STL. Mais sauf dans les cas spéciaux, où il implémente quelque
chose qui n'a réelement pas d'équivalent dans la STL, j'utilise
la bibliothèque standard. Par considération à ceux qui vont lire
mon code.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jun 10, 12:31 pm, (Pascal J. Bourguignon) wrote:
Gabriel Dos Reis writes:
[...]
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).
Ce qui présentera un autre jeu de problèmes : si tu dois le développer, c'est un travail important, supplémentaire, et même si tu l'as déjà sous la main, c'est un travail supplémentaire pour chacun qui lit ton code de l'apprendre. Moi aussi, je trouve que ma bibliothèque pré-standard était supérieur à la STL. Mais sauf dans les cas spéciaux, où il implémente quelque chose qui n'a réelement pas d'équivalent dans la STL, j'utilise la bibliothèque standard. Par considération à ceux qui vont lire mon code.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
On Jun 10, 2:26 pm, (Pascal J. Bourguignon) wrote:
Fabien LE LEZ writes:
> 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...
Moi non plus. Sans les histoires d'argent, je ferais de la musique, non de l'informatique.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jun 10, 2:26 pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
Fabien LE LEZ <grams...@gramster.com> writes:
> On Wed, 10 Jun 2009 12:31:30 +0200, p...@informatimago.com (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...
Moi non plus. Sans les histoires d'argent, je ferais de la
musique, non de l'informatique.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jun 10, 2:26 pm, (Pascal J. Bourguignon) wrote:
Fabien LE LEZ writes:
> 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...
Moi non plus. Sans les histoires d'argent, je ferais de la musique, non de l'informatique.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
On Jun 10, 12:20 pm, Gabriel Dos Reis wrote:
James Kanze writes:
[...]
| La fonction binary_search renvoie une paire d'itérateurs, de
quelle version ?
Je me suis déjà corrigé. Je l'ai confondu avec equal_range. (Il faut dire que je ne me suis jamais servi ni d'une ni de l'autre. Jusqu'ici, pour la recherche binominale, il n'y a que lower_bound qui m'a servi.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jun 10, 12:20 pm, Gabriel Dos Reis <g...@cse.tamu.edu> wrote:
James Kanze <james.ka...@gmail.com> writes:
[...]
| La fonction binary_search renvoie une paire d'itérateurs, de
quelle version ?
Je me suis déjà corrigé. Je l'ai confondu avec equal_range. (Il
faut dire que je ne me suis jamais servi ni d'une ni de l'autre.
Jusqu'ici, pour la recherche binominale, il n'y a que
lower_bound qui m'a servi.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
| La fonction binary_search renvoie une paire d'itérateurs, de
quelle version ?
Je me suis déjà corrigé. Je l'ai confondu avec equal_range. (Il faut dire que je ne me suis jamais servi ni d'une ni de l'autre. Jusqu'ici, pour la recherche binominale, il n'y a que lower_bound qui m'a servi.)
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
pjb
James Kanze writes:
Un langage n'est jamais parfait, et dans ce cas, l'état actuel est « good enough », même s'il n'est pas parfait de point de vue théorique.
Ça c'est bien vrai. Que dirais tu d'un langage imparfait, mais perfectible facilement par l'utilisateur ?
-- __Pascal Bourguignon__
James Kanze <james.kanze@gmail.com> writes:
Un langage n'est jamais parfait, et dans ce cas, l'état actuel
est « good enough », même s'il n'est pas parfait de point de vue
théorique.
Ça c'est bien vrai. Que dirais tu d'un langage imparfait, mais
perfectible facilement par l'utilisateur ?
