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 Thu, 11 Jun 2009 10:20:38 +0200, (Pascal J. Bourguignon):
Que dirais tu d'un langage imparfait
Sous-entendrais-tu que Lisp puisse être imparfait ? :-O Vade retro satanas !
Ce n'est pas qu'il soit imparfait, mais comme nous vivons dans un monde imparfait, il faut 'parfaire' lisp pour l'adapter à ce monde. Chacun a ses propres circonstances, d'où l'intérêt d'utiliser un langage perfectible, que chacun puisse modifier et adapter à ses contingences, sans avoir à passer par un grand prêtre ou un comité de standardisation.
The unavoidable conclusion is that no single language will ever be universally appropriate, no matter how clever its design. So we adopted a different solution. Rather thans upplying the user with a fixed, single point in the space of all language designs and implementations, we would isntead support a region of possible designs within that overall space. This is the essence of the metaobject protocol approach. In the case of CLOS, for example, instead of providing a single fixed language, with a single implementation strategy, the metaobject protocol extends a basic or "default" CLOS by providing a surrounding region of alternatives. Users are free to move to whatever point inthat region best matches their particular requirements.
-- in "The Art of the Metaobject Protocol"
Cette philosophie est appliquée à tout Lisp, pas seulement à son système d'objets.
Dans une certaine mesure, C++ essaye de faire la même chose, mais au lieu de permettre aux utilisateurs de modifier le langage, il se contente de fournir quelques points autour de chaque fonctionalité. Par exemple, on a le choix entre des méthodes virtuelles ou non virtuelles, pour avoir une sélection de la méthode à l'exécution ou à la compilation. Mais l'utilisateur ne peut pas implémenter son propre mécanisme de sélection de méthode. Ou l'utilisateur ne peut pas implémenter sa propre instruction de boucle (par exemple, pour cacher les détails de l'utilisation des itérateurs ; boost essaye de fournir une telle instruction "foreach" avec de grandes difficultés, comparé à Lisp où ceci est trivial).
-- __Pascal Bourguignon__
Fabien LE LEZ <gramster@gramster.com> writes:
On Thu, 11 Jun 2009 10:20:38 +0200, pjb@informatimago.com (Pascal J.
Bourguignon):
Que dirais tu d'un langage imparfait
Sous-entendrais-tu que Lisp puisse être imparfait ? :-O
Vade retro satanas !
Ce n'est pas qu'il soit imparfait, mais comme nous vivons dans un
monde imparfait, il faut 'parfaire' lisp pour l'adapter à ce monde.
Chacun a ses propres circonstances, d'où l'intérêt d'utiliser un
langage perfectible, que chacun puisse modifier et adapter à ses
contingences, sans avoir à passer par un grand prêtre ou un comité de
standardisation.
The unavoidable conclusion is that no single language will ever
be universally appropriate, no matter how clever its design. So
we adopted a different solution. Rather thans upplying the user
with a fixed, single point in the space of all language designs
and implementations, we would isntead support a region of
possible designs within that overall space. This is the essence
of the metaobject protocol approach. In the case of CLOS, for
example, instead of providing a single fixed language, with a
single implementation strategy, the metaobject protocol extends a
basic or "default" CLOS by providing a surrounding region of
alternatives. Users are free to move to whatever point inthat
region best matches their particular requirements.
-- in "The Art of the Metaobject Protocol"
Cette philosophie est appliquée à tout Lisp, pas seulement à son
système d'objets.
Dans une certaine mesure, C++ essaye de faire la même chose, mais au
lieu de permettre aux utilisateurs de modifier le langage, il se
contente de fournir quelques points autour de chaque fonctionalité.
Par exemple, on a le choix entre des méthodes virtuelles ou non
virtuelles, pour avoir une sélection de la méthode à l'exécution ou à
la compilation. Mais l'utilisateur ne peut pas implémenter son propre
mécanisme de sélection de méthode. Ou l'utilisateur ne peut pas
implémenter sa propre instruction de boucle (par exemple, pour cacher
les détails de l'utilisation des itérateurs ; boost essaye de fournir
une telle instruction "foreach" avec de grandes difficultés, comparé à
Lisp où ceci est trivial).
On Thu, 11 Jun 2009 10:20:38 +0200, (Pascal J. Bourguignon):
Que dirais tu d'un langage imparfait
Sous-entendrais-tu que Lisp puisse être imparfait ? :-O Vade retro satanas !
Ce n'est pas qu'il soit imparfait, mais comme nous vivons dans un monde imparfait, il faut 'parfaire' lisp pour l'adapter à ce monde. Chacun a ses propres circonstances, d'où l'intérêt d'utiliser un langage perfectible, que chacun puisse modifier et adapter à ses contingences, sans avoir à passer par un grand prêtre ou un comité de standardisation.
The unavoidable conclusion is that no single language will ever be universally appropriate, no matter how clever its design. So we adopted a different solution. Rather thans upplying the user with a fixed, single point in the space of all language designs and implementations, we would isntead support a region of possible designs within that overall space. This is the essence of the metaobject protocol approach. In the case of CLOS, for example, instead of providing a single fixed language, with a single implementation strategy, the metaobject protocol extends a basic or "default" CLOS by providing a surrounding region of alternatives. Users are free to move to whatever point inthat region best matches their particular requirements.
-- in "The Art of the Metaobject Protocol"
Cette philosophie est appliquée à tout Lisp, pas seulement à son système d'objets.
Dans une certaine mesure, C++ essaye de faire la même chose, mais au lieu de permettre aux utilisateurs de modifier le langage, il se contente de fournir quelques points autour de chaque fonctionalité. Par exemple, on a le choix entre des méthodes virtuelles ou non virtuelles, pour avoir une sélection de la méthode à l'exécution ou à la compilation. Mais l'utilisateur ne peut pas implémenter son propre mécanisme de sélection de méthode. Ou l'utilisateur ne peut pas implémenter sa propre instruction de boucle (par exemple, pour cacher les détails de l'utilisation des itérateurs ; boost essaye de fournir une telle instruction "foreach" avec de grandes difficultés, comparé à Lisp où ceci est trivial).
-- __Pascal Bourguignon__
Gabriel Dos Reis
James Kanze writes:
| On Jun 10, 12:12 pm, Gabriel Dos Reis wrote:
James Kanze writes:
| On Jun 9, 12:22 pm, Michael Doubez wrote:>> On 9 juin, 11:22, (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:
Honêtement, jusqu'à ce qu'un client me demande d'utiliser la STL, dan s 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).
Comment fais-tu pour justifier le coût supplémentaire de déveleppement de ta propre bibliothèque au client ?
Je ne suis pas sûr qu'un client soit rassuré par quelqu'un qui préfère utiliser sa bibliothèque à celle qui est standard.
-- -Stan
On 10 juin, 12:31, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
Honêtement, jusqu'à ce qu'un client me demande d'utiliser la STL, dan s
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).
Comment fais-tu pour justifier le coût supplémentaire
de déveleppement de ta propre bibliothèque au client ?
Je ne suis pas sûr qu'un client soit rassuré par quelqu'un
qui préfère utiliser sa bibliothèque à celle qui est standard.
Honêtement, jusqu'à ce qu'un client me demande d'utiliser la STL, dan s 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).
Comment fais-tu pour justifier le coût supplémentaire de déveleppement de ta propre bibliothèque au client ?
Je ne suis pas sûr qu'un client soit rassuré par quelqu'un qui préfère utiliser sa bibliothèque à celle qui est standard.
-- -Stan
Mathias Gaunard
On 8 juin, 16:47, "Christian PANEL" wrote:
bonjour,
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.
C'est une bibliothèque de base assez simple. Elle a pas mal de défauts, une bonne part devant étant corrigée dans C+ +0x, mais certains la voient comme une oeuvre d'art. C'est vrai tout de même que comparé à du code du développeur C++ moyen, c'est bien au dessus et qu'en pratique, il n'y a pas vraiment de meilleure solution à part d'implémenter sa propre version avec des extensions, ce qui nécessite tout de même d'être un expert et d'avoir du temps à consacrer pour debugger, benchmarker et tester.
je pense alors que pour avoir des conteneurs efficaces, il est nécessai re au moins de dériver ces conteneurs de base. Mais la aussi je me heurte à quelques problèmes : supposons tout simp lement que je veuille créer un conteneur tableau trié d'objets (et qui le re stent lors d'ajouts).
Je suppose que vous voulez dériver de vector pour implémenter un vecteur (mutable) trié. Cas d'école de chose à ne surtout pas faire en orienté objet : ce genre de chose ne peut pas cadrer au LSP.
De manière générale, il ne faut pas hériter publiquement de types n on conçus pour à part pour réaliser un genre de typedef.
On 8 juin, 16:47, "Christian PANEL" <c.pa...@free.fr> wrote:
bonjour,
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.
C'est une bibliothèque de base assez simple.
Elle a pas mal de défauts, une bonne part devant étant corrigée dans C+
+0x, mais certains la voient comme une oeuvre d'art. C'est vrai tout
de même que comparé à du code du développeur C++ moyen, c'est bien au
dessus et qu'en pratique, il n'y a pas vraiment de meilleure solution
à part d'implémenter sa propre version avec des extensions, ce qui
nécessite tout de même d'être un expert et d'avoir du temps à
consacrer pour debugger, benchmarker et tester.
je pense alors que pour avoir des conteneurs efficaces, il est nécessai re au
moins de dériver ces conteneurs de base.
Mais la aussi je me heurte à quelques problèmes : supposons tout simp lement
que je veuille créer un conteneur tableau trié d'objets (et qui le re stent
lors d'ajouts).
Je suppose que vous voulez dériver de vector pour implémenter un
vecteur (mutable) trié.
Cas d'école de chose à ne surtout pas faire en orienté objet : ce
genre de chose ne peut pas cadrer au LSP.
De manière générale, il ne faut pas hériter publiquement de types n on
conçus pour à part pour réaliser un genre de typedef.
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.
C'est une bibliothèque de base assez simple. Elle a pas mal de défauts, une bonne part devant étant corrigée dans C+ +0x, mais certains la voient comme une oeuvre d'art. C'est vrai tout de même que comparé à du code du développeur C++ moyen, c'est bien au dessus et qu'en pratique, il n'y a pas vraiment de meilleure solution à part d'implémenter sa propre version avec des extensions, ce qui nécessite tout de même d'être un expert et d'avoir du temps à consacrer pour debugger, benchmarker et tester.
je pense alors que pour avoir des conteneurs efficaces, il est nécessai re au moins de dériver ces conteneurs de base. Mais la aussi je me heurte à quelques problèmes : supposons tout simp lement que je veuille créer un conteneur tableau trié d'objets (et qui le re stent lors d'ajouts).
Je suppose que vous voulez dériver de vector pour implémenter un vecteur (mutable) trié. Cas d'école de chose à ne surtout pas faire en orienté objet : ce genre de chose ne peut pas cadrer au LSP.
De manière générale, il ne faut pas hériter publiquement de types n on conçus pour à part pour réaliser un genre de typedef.
