Compilateur et STL

Marc Boyer

20/11/2003 à 14:31

Seb wrote:

Bonjour,

J'utilisais pour un projet un compilateur C++ auquel était ajouté une STL
(de RogueWave). Nous avons changé de compilateur (gcc) et je constate qu'une
implémentation de la STL est disponible.

Je voulais savoir si "par définition", un compilateur actuel était
nécessairement livré avec une implémentation de la STL.

La norme C++ définit l'interface de la STL, interface qui
précise même les complexité de certaines implémentations.
Donc, un compilateur qui s'engage à compiler du C++
devrait fournir une STL.
Ceci étant dit, je ne connais pas de compilateur qui
s'engage contractuellement à compiler tout le langage C++
tel que définit dans la norme.

Si oui, quel intérêt
peut-on avoir à en choisir une autre qui est payante. J'imagine que tout ce
qui est proposé (vu de l'extérieur) est pareil : mêmes fonctionnalités,
mêmes templates.

Meilleures perfs à l'exécution ? Fonctionnalités supplémentaires ?
Plus faible nombre de bug ? Plus rapide à compiler ?
Intégration avec le débugueur ?

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Seb

20/11/2003 à 14:37

"Marc Boyer" a écrit dans le message
news: bpifob$c5s$

Seb wrote:
Bonjour,

J'utilisais pour un projet un compilateur C++ auquel était ajouté une
STL

(de RogueWave). Nous avons changé de compilateur (gcc) et je constate
qu'une

implémentation de la STL est disponible.

Je voulais savoir si "par définition", un compilateur actuel était
nécessairement livré avec une implémentation de la STL.

La norme C++ définit l'interface de la STL, interface qui
précise même les complexité de certaines implémentations.
Donc, un compilateur qui s'engage à compiler du C++
devrait fournir une STL.
Ceci étant dit, je ne connais pas de compilateur qui
s'engage contractuellement à compiler tout le langage C++
tel que définit dans la norme.

Si oui, quel intérêt
peut-on avoir à en choisir une autre qui est payante. J'imagine que tout
ce

qui est proposé (vu de l'extérieur) est pareil : mêmes fonctionnalités,
mêmes templates.

Meilleures perfs à l'exécution ? Fonctionnalités supplémentaires ?
Plus faible nombre de bug ? Plus rapide à compiler ?
Intégration avec le débugueur ?

D'accord pour tout, mais "Fonctions supplémentaires" : si on parle de la
STL, c'est toujours les memes fonctions non ? (celles que reprend la norme)
d'ou ma question : un éditeur peut-il rajouter des choses dans la STL ?

Sébastien

B. Monsuez

20/11/2003 à 14:40

Seb wrote:

Bonjour,

J'utilisais pour un projet un compilateur C++ auquel était ajouté une STL
(de RogueWave). Nous avons changé de compilateur (gcc) et je constate qu'une
implémentation de la STL est disponible.

Je voulais savoir si "par définition", un compilateur actuel était
nécessairement livré avec une implémentation de la STL. Si oui, quel intérêt
peut-on avoir à en choisir une autre qui est payante. J'imagine que tout ce
qui est proposé (vu de l'extérieur) est pareil : mêmes fonctionnalités,
mêmes templates.

Sébastien

Il est possible d'utiliser d'autres implantations de la STL,

certaines sont gratuites d'autres payantes comme par exemple
STLport (gratuite) ou celle de Plauger ou RogueWare qui sont
payantes.

Ce qui est vu de l'extérieur est censé correspondre à la norme.
Mais les implantations et les performances différent. Ceci
peut avoir un impact sur les performances de l'application
mais aussi sur ce qu'il est possible d'exprimer en usant de la
STL, je pense notamment à certains problèmes avec les locale !

Personnellement, dans le code que j'écris, je supporte plus
d'une implantation et j'ai du code spécifique pour contourner
les limitations de certaines implantations.

Un compilateur habituellement est livré avec une implantation
de la STL adaptée au compilateur (même 2 dans le cas de Borland
par exemple). Comeau par exemple ne livre pas systématiquement
de STL. Il peut être aussi judicieux d'user de la même
bibliothéque sous plusieurs compilateurs (par exemple Plauger,
STLport).

Enfin, la STL est une bibliothèque et reste une bibliothèque ne
devant surtout pas amener les personnes à se cantonner à l'usage
de cette seule bibliothèque et pis encore de la seule
bibliothèque livrée avec le compilateur (par opposition à la C
Runtime Library), même si de facto, quand on livre une
bibliothèque devant tourner avec un compilateur, on verifie qu'elle
compile avec la STL par défaut du compilateur).
Elle offre quelques éléments de base, une philosophie pouvant
être intéressante pour certaines applications, mais pas pour
toutes les applications, mais ca s'arrête là aussi.

Enfin, certaines implantations proposent des extensions à la
bibliothèque standard, certaines seront présentes dans la
norme future, d'autres non.

Un défaut de la STL paradoxalement, c'est justement que beaucoup de
programmeurs s'imaginent par la suite que c'est comme cela qu'il faut
écrire du C++. Hors ce n'est qu'une utilisation de C++ parmi d'autres.

La richesse de C++, c'est justement qu'il n'y a pas un style d'écriture
comme en Java ou en Smalltalk par exemple mais des styles. Et au final,
une richesse qui bien maitrisée permet d'écrire du code aussi facilement
qu'en Java. Mais l'investissement initial est beaucoup plus lourd.

--
B. Monsuez
-------------------------------------------------
Ingénieur-Expert --- Cabinet d'ingénièrie Monsuez
Sureté des logiciels/composants
Compilation/Analyse statique

Seb wrote:

Bonjour,

J'utilisais pour un projet un compilateur C++ auquel était ajouté une STL
(de RogueWave). Nous avons changé de compilateur (gcc) et je constate qu'une
implémentation de la STL est disponible.

Je voulais savoir si "par définition", un compilateur actuel était
nécessairement livré avec une implémentation de la STL. Si oui, quel intérêt
peut-on avoir à en choisir une autre qui est payante. J'imagine que tout ce
qui est proposé (vu de l'extérieur) est pareil : mêmes fonctionnalités,
mêmes templates.

Sébastien

Il est possible d'utiliser d'autres implantations de la STL,

certaines sont gratuites d'autres payantes comme par exemple
STLport (gratuite) ou celle de Plauger ou RogueWare qui sont
payantes.

Ce qui est vu de l'extérieur est censé correspondre à la norme.
Mais les implantations et les performances différent. Ceci
peut avoir un impact sur les performances de l'application
mais aussi sur ce qu'il est possible d'exprimer en usant de la
STL, je pense notamment à certains problèmes avec les locale !

Personnellement, dans le code que j'écris, je supporte plus
d'une implantation et j'ai du code spécifique pour contourner
les limitations de certaines implantations.

Un compilateur habituellement est livré avec une implantation
de la STL adaptée au compilateur (même 2 dans le cas de Borland
par exemple). Comeau par exemple ne livre pas systématiquement
de STL. Il peut être aussi judicieux d'user de la même
bibliothéque sous plusieurs compilateurs (par exemple Plauger,
STLport).

Enfin, la STL est une bibliothèque et reste une bibliothèque ne
devant surtout pas amener les personnes à se cantonner à l'usage
de cette seule bibliothèque et pis encore de la seule
bibliothèque livrée avec le compilateur (par opposition à la C
Runtime Library), même si de facto, quand on livre une
bibliothèque devant tourner avec un compilateur, on verifie qu'elle
compile avec la STL par défaut du compilateur).
Elle offre quelques éléments de base, une philosophie pouvant
être intéressante pour certaines applications, mais pas pour
toutes les applications, mais ca s'arrête là aussi.

Enfin, certaines implantations proposent des extensions à la
bibliothèque standard, certaines seront présentes dans la
norme future, d'autres non.

Un défaut de la STL paradoxalement, c'est justement que beaucoup de
programmeurs s'imaginent par la suite que c'est comme cela qu'il faut
écrire du C++. Hors ce n'est qu'une utilisation de C++ parmi d'autres.

La richesse de C++, c'est justement qu'il n'y a pas un style d'écriture
comme en Java ou en Smalltalk par exemple mais des styles. Et au final,
une richesse qui bien maitrisée permet d'écrire du code aussi facilement
qu'en Java. Mais l'investissement initial est beaucoup plus lourd.

--
B. Monsuez
-------------------------------------------------
Ingénieur-Expert --- Cabinet d'ingénièrie Monsuez
Sureté des logiciels/composants
Compilation/Analyse statique

Vous avez filtré cet utilisateur ! Consultez son message

Seb wrote:

Bonjour,

J'utilisais pour un projet un compilateur C++ auquel était ajouté une STL
(de RogueWave). Nous avons changé de compilateur (gcc) et je constate qu'une
implémentation de la STL est disponible.

Je voulais savoir si "par définition", un compilateur actuel était
nécessairement livré avec une implémentation de la STL. Si oui, quel intérêt
peut-on avoir à en choisir une autre qui est payante. J'imagine que tout ce
qui est proposé (vu de l'extérieur) est pareil : mêmes fonctionnalités,
mêmes templates.

Sébastien

Il est possible d'utiliser d'autres implantations de la STL,

certaines sont gratuites d'autres payantes comme par exemple
STLport (gratuite) ou celle de Plauger ou RogueWare qui sont
payantes.

Ce qui est vu de l'extérieur est censé correspondre à la norme.
Mais les implantations et les performances différent. Ceci
peut avoir un impact sur les performances de l'application
mais aussi sur ce qu'il est possible d'exprimer en usant de la
STL, je pense notamment à certains problèmes avec les locale !

Personnellement, dans le code que j'écris, je supporte plus
d'une implantation et j'ai du code spécifique pour contourner
les limitations de certaines implantations.

Un compilateur habituellement est livré avec une implantation
de la STL adaptée au compilateur (même 2 dans le cas de Borland
par exemple). Comeau par exemple ne livre pas systématiquement
de STL. Il peut être aussi judicieux d'user de la même
bibliothéque sous plusieurs compilateurs (par exemple Plauger,
STLport).

Enfin, la STL est une bibliothèque et reste une bibliothèque ne
devant surtout pas amener les personnes à se cantonner à l'usage
de cette seule bibliothèque et pis encore de la seule
bibliothèque livrée avec le compilateur (par opposition à la C
Runtime Library), même si de facto, quand on livre une
bibliothèque devant tourner avec un compilateur, on verifie qu'elle
compile avec la STL par défaut du compilateur).
Elle offre quelques éléments de base, une philosophie pouvant
être intéressante pour certaines applications, mais pas pour
toutes les applications, mais ca s'arrête là aussi.

Enfin, certaines implantations proposent des extensions à la
bibliothèque standard, certaines seront présentes dans la
norme future, d'autres non.

Un défaut de la STL paradoxalement, c'est justement que beaucoup de
programmeurs s'imaginent par la suite que c'est comme cela qu'il faut
écrire du C++. Hors ce n'est qu'une utilisation de C++ parmi d'autres.

La richesse de C++, c'est justement qu'il n'y a pas un style d'écriture
comme en Java ou en Smalltalk par exemple mais des styles. Et au final,
une richesse qui bien maitrisée permet d'écrire du code aussi facilement
qu'en Java. Mais l'investissement initial est beaucoup plus lourd.

--
B. Monsuez
-------------------------------------------------
Ingénieur-Expert --- Cabinet d'ingénièrie Monsuez
Sureté des logiciels/composants
Compilation/Analyse statique

Mickael Pointier

20/11/2003 à 14:43

Meilleures perfs à l'exécution ? Fonctionnalités supplémentaires ?
Plus faible nombre de bug ? Plus rapide à compiler ?
Intégration avec le débugueur ?

D'accord pour tout, mais "Fonctions supplémentaires" : si on parle de
la STL, c'est toujours les memes fonctions non ? (celles que reprend
la norme) d'ou ma question : un éditeur peut-il rajouter des choses
dans la STL ?

"Fonctionnalité"!="Fonctions".

Rien n'empeche par exemple de rajouter des fonctionnalités permettant
d'aider pendant le débogage ou la mise au point, donner des statistiques
sur l'allocation mémoire, ...

Mike

Marc Boyer

20/11/2003 à 14:56

Seb wrote:

D'accord pour tout, mais "Fonctions supplémentaires" : si on parle de la
STL, c'est toujours les memes fonctions non ? (celles que reprend la norme)
d'ou ma question : un éditeur peut-il rajouter des choses dans la STL ?

En ce qui concerne les fonctionnalités supplémentaires, il peut
ajouter d'autres conteneurs, d'autres algorithmes.
Il peut aussi augmenter l'interface des conteneurs par exemple.
Ajouter un reserve() a dequeu par exemple. Ou avoir un getStat sur
une liste qui donnerait des stats sur les moyennes lecture/insertion
pour voir si on aurait pas mieux avec un vector ou un dequeu.

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Jean-Marc Bourguet

20/11/2003 à 16:58

"Seb" writes:

J'utilisais pour un projet un compilateur C++ auquel était ajouté
une STL (de RogueWave). Nous avons changé de compilateur (gcc) et je
constate qu'une implémentation de la STL est disponible.

Je voulais savoir si "par définition", un compilateur actuel était
nécessairement livré avec une implémentation de la STL. Si oui, quel
intérêt peut-on avoir à en choisir une autre qui est
payante. J'imagine que tout ce qui est proposé (vu de l'extérieur)
est pareil : mêmes fonctionnalités, mêmes templates.

Tout depend de ce que tu entends par STL. La norme adoptee en 1998
comprend une bibliotheque standard dont une partie est une adaptation
d'une partie de la bibliotheque de Stepanov et Lee appelee STL (qui a
continue a etre maintenue pendant un temps apres la publication de la
norme).

On se trouve maintenant des gens qui appellent STL
- toute la bibliotheque standard
- la partie de la bibliotheque standard qui provient de la
bibliotheque de Stepanov et Lee
- la bibliotheque de Stepanov et Lee.

On peut s'attendre a ce que tout compilateur recent implemente la
bibliotheque standardisee (parfois avec des extensions qui proviennent
parfois de la partie de la bibliotheque de Stepanov et Lee qui n'a pas
ete normalisee ou ete developpee apres la normalisation).

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Mathieu Peyréga

21/11/2003 à 00:00

En ce qui concerne les fonctionnalités supplémentaires, il peut
ajouter d'autres conteneurs, d'autres algorithmes.
Il peut aussi augmenter l'interface des conteneurs par exemple.
Ajouter un reserve() a dequeu par exemple. Ou avoir un getStat sur
une liste qui donnerait des stats sur les moyennes lecture/insertion
pour voir si on aurait pas mieux avec un vector ou un dequeu.

Marc Boyer

Je crois aussi que la STL de roguewave implémente des fonctionnalité de
gestion MultiThread safe qui ne font (à ma connaissance) pas partie de
la norme mais qui peuvent parfois avoir un intérêt...
(quoiqu'on puisse l'implémenter soi-même relativement aisément)

kanze

21/11/2003 à 09:42

"Seb" wrote in message
news:<bpib3r$9vv$...

J'utilisais pour un projet un compilateur C++ auquel était ajouté une
STL (de RogueWave). Nous avons changé de compilateur (gcc) et je
constate qu'une implémentation de la STL est disponible.

Je voulais savoir si "par définition", un compilateur actuel était
nécessairement livré avec une implémentation de la STL.

En théorie, oui.

Dans la pratique : on est souvent amené à ne pas utiliser la dernière
version du compilateur, pour diverses raisons, et il est possible, voire
probable, que pour certaines plateformes embarquées, à mémoire
extrèmement limitée, qu'on n'a pas toute la STL, ou même si le
compilateur est livré avec elle, on ne peut pas s'en servir. Si tu ne
cibles que les versions de compilateur rélativement récentes sur des
plateformes courantes, en revanche, je crois que la théorie se rejoint à
la pratique en ce qui concerne la présence de la STL.

Si oui, quel intérêt peut-on avoir à en choisir une autre qui est
payante.

Ça dépend. Toutes autres choses égales, on doit effectivement préférer
toujours la version de la bibliothèque livrée avec le compilateur. Mais
il peut y avoir des motives pour en prendre un autre :

Portabilité : comme la reste du langage, il y a des variations dans les
différentes implémentations de la STL. Utiliser la même
implémentation sur toutes les plateformes pourrait facilité la
portabilité. (Enfin, c'est une raison plutôt théorique, à mon avis.
Les variations dans le langage même sont bien plus grandes que
celles dans les implémentations de la STL. En fin de compte, pour la
portabilité, tu utilises g++ partout, et tu as le même compilateur
ET la même bibliothèque.)

Features : pendant longtemps, la STLPort était la seule implémentation
avec un mode debug. Même aujourd'hui, je crois qu'il n'y a que la
STLPort et Dinkumware qui l'ont. C'est un argument très fort en
faveur d'une de ces bibliothèques.

Performances : je trouve que ce ne doit pas être une raison, mais
malheureusement, certaines bibliothèques (comme la version de Rogue
Wave qui vient avec Sun CC 5.1) sont tellement lentes que d'être
quasiment inutilisable.

J'imagine que tout ce qui est proposé (vu de l'extérieur) est pareil :
mêmes fonctionnalités, mêmes templates.

À quelques détails près. La plupart ont des extensions (comme hash_map),
et ces extensions ne sont pas forcément compatible. Mais la grande
différence, c'est la présence ou l'absense d'une mode debug.

Si tu fais du multi-thread, il faut voir aussi. Autant que je sache,
toutes les implémentations pour des environements multi-threaded reclame
le « thread safety », mais il y a au moins trois définitions différentes
de ce que « thread safe » signifie :

- G++ dit que c'est à l'utilisateur de protéger tous les accès dès
qu'on accède à l'objet depuis plus d'un thread. Y compris si tous
les accès sont uniquement en lecture. (C'est donc moins de garanties
que ce qu'on a pour un int, au moins sous Posix.)

- SGI et la STLPort font les mêmes garanties qu'on a pour un objet de
type de base sous Posix : c'est à l'utilisateur de protéger tous les
accès dès qu'il y accès depuis plus d'un thread ET qu'au moins un
des threads peut modifier l'objet. Si tous les accès sont en lecture
seulement, il n'y a pas besoin de protection.

- Rogue Wave prend un lock dans chaque fonction, de façon qu'en
principe, l'utilisateur n'a jamais besoin de prendre un lock. Je dis
bien en principe, parce qu'évidemment, son lock ne s'étend pas au
delà de la fonction, et donc ne protège pas la référence renvoyée
par std::vector<>::operator[], par exemple.

Dans l'ensemble, je trouve que la troisième définition n'apporte rien
par rapport à la deuxième dans la pratique -- la granularité est trop
petite, et a un coût énorme en temps d'exécution. (Dans notre cas, une
facteur dix dans la performance totale du programme entre la
bibliothèque Rogue Wave livrée avec Sun CC et la STLPort. Ce qui est,
toujours dans notre cas, la différence entre une performance acceptable,
et une performance inacceptable.)

Je n'aime pas la définition utilisée par g++. Pas tellement qu'elle a un
défaut en soi (ça, on pourrait en discuter), mais surtout parce qu'elle
est différente que celle proposée généralement par le système pour les
types qu'il connaît. Si j'écris :

int const i = 42 ;
std::string const t( "abc" ) ;

Pourquoi est-ce qu'il me faut un lock pour chaque accès à t, quand il ne
m'en faut pas pour les accès à i ?

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

"Seb" <nospam@yahoo.fr> wrote in message
news:<bpib3r$9vv$1@s1.read.news.oleane.net>...

J'utilisais pour un projet un compilateur C++ auquel était ajouté une
STL (de RogueWave). Nous avons changé de compilateur (gcc) et je
constate qu'une implémentation de la STL est disponible.

Je voulais savoir si "par définition", un compilateur actuel était
nécessairement livré avec une implémentation de la STL.

En théorie, oui.

Dans la pratique : on est souvent amené à ne pas utiliser la dernière
version du compilateur, pour diverses raisons, et il est possible, voire
probable, que pour certaines plateformes embarquées, à mémoire
extrèmement limitée, qu'on n'a pas toute la STL, ou même si le
compilateur est livré avec elle, on ne peut pas s'en servir. Si tu ne
cibles que les versions de compilateur rélativement récentes sur des
plateformes courantes, en revanche, je crois que la théorie se rejoint à
la pratique en ce qui concerne la présence de la STL.

Si oui, quel intérêt peut-on avoir à en choisir une autre qui est
payante.

Ça dépend. Toutes autres choses égales, on doit effectivement préférer
toujours la version de la bibliothèque livrée avec le compilateur. Mais
il peut y avoir des motives pour en prendre un autre :

Portabilité : comme la reste du langage, il y a des variations dans les
différentes implémentations de la STL. Utiliser la même
implémentation sur toutes les plateformes pourrait facilité la
portabilité. (Enfin, c'est une raison plutôt théorique, à mon avis.
Les variations dans le langage même sont bien plus grandes que
celles dans les implémentations de la STL. En fin de compte, pour la
portabilité, tu utilises g++ partout, et tu as le même compilateur
ET la même bibliothèque.)

Features : pendant longtemps, la STLPort était la seule implémentation
avec un mode debug. Même aujourd'hui, je crois qu'il n'y a que la
STLPort et Dinkumware qui l'ont. C'est un argument très fort en
faveur d'une de ces bibliothèques.

Performances : je trouve que ce ne doit pas être une raison, mais
malheureusement, certaines bibliothèques (comme la version de Rogue
Wave qui vient avec Sun CC 5.1) sont tellement lentes que d'être
quasiment inutilisable.

J'imagine que tout ce qui est proposé (vu de l'extérieur) est pareil :
mêmes fonctionnalités, mêmes templates.

À quelques détails près. La plupart ont des extensions (comme hash_map),
et ces extensions ne sont pas forcément compatible. Mais la grande
différence, c'est la présence ou l'absense d'une mode debug.

Si tu fais du multi-thread, il faut voir aussi. Autant que je sache,
toutes les implémentations pour des environements multi-threaded reclame
le « thread safety », mais il y a au moins trois définitions différentes
de ce que « thread safe » signifie :

- G++ dit que c'est à l'utilisateur de protéger tous les accès dès
qu'on accède à l'objet depuis plus d'un thread. Y compris si tous
les accès sont uniquement en lecture. (C'est donc moins de garanties
que ce qu'on a pour un int, au moins sous Posix.)

- SGI et la STLPort font les mêmes garanties qu'on a pour un objet de
type de base sous Posix : c'est à l'utilisateur de protéger tous les
accès dès qu'il y accès depuis plus d'un thread ET qu'au moins un
des threads peut modifier l'objet. Si tous les accès sont en lecture
seulement, il n'y a pas besoin de protection.

- Rogue Wave prend un lock dans chaque fonction, de façon qu'en
principe, l'utilisateur n'a jamais besoin de prendre un lock. Je dis
bien en principe, parce qu'évidemment, son lock ne s'étend pas au
delà de la fonction, et donc ne protège pas la référence renvoyée
par std::vector<>::operator[], par exemple.

Dans l'ensemble, je trouve que la troisième définition n'apporte rien
par rapport à la deuxième dans la pratique -- la granularité est trop
petite, et a un coût énorme en temps d'exécution. (Dans notre cas, une
facteur dix dans la performance totale du programme entre la
bibliothèque Rogue Wave livrée avec Sun CC et la STLPort. Ce qui est,
toujours dans notre cas, la différence entre une performance acceptable,
et une performance inacceptable.)

Je n'aime pas la définition utilisée par g++. Pas tellement qu'elle a un
défaut en soi (ça, on pourrait en discuter), mais surtout parce qu'elle
est différente que celle proposée généralement par le système pour les
types qu'il connaît. Si j'écris :

int const i = 42 ;
std::string const t( "abc" ) ;

Pourquoi est-ce qu'il me faut un lock pour chaque accès à t, quand il ne
m'en faut pas pour les accès à i ?

--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Vous avez filtré cet utilisateur ! Consultez son message

"Seb" wrote in message
news:<bpib3r$9vv$...

J'utilisais pour un projet un compilateur C++ auquel était ajouté une
STL (de RogueWave). Nous avons changé de compilateur (gcc) et je
constate qu'une implémentation de la STL est disponible.

Je voulais savoir si "par définition", un compilateur actuel était
nécessairement livré avec une implémentation de la STL.

En théorie, oui.

Dans la pratique : on est souvent amené à ne pas utiliser la dernière
version du compilateur, pour diverses raisons, et il est possible, voire
probable, que pour certaines plateformes embarquées, à mémoire
extrèmement limitée, qu'on n'a pas toute la STL, ou même si le
compilateur est livré avec elle, on ne peut pas s'en servir. Si tu ne
cibles que les versions de compilateur rélativement récentes sur des
plateformes courantes, en revanche, je crois que la théorie se rejoint à
la pratique en ce qui concerne la présence de la STL.

Si oui, quel intérêt peut-on avoir à en choisir une autre qui est
payante.

Ça dépend. Toutes autres choses égales, on doit effectivement préférer
toujours la version de la bibliothèque livrée avec le compilateur. Mais
il peut y avoir des motives pour en prendre un autre :

Portabilité : comme la reste du langage, il y a des variations dans les
différentes implémentations de la STL. Utiliser la même
implémentation sur toutes les plateformes pourrait facilité la
portabilité. (Enfin, c'est une raison plutôt théorique, à mon avis.
Les variations dans le langage même sont bien plus grandes que
celles dans les implémentations de la STL. En fin de compte, pour la
portabilité, tu utilises g++ partout, et tu as le même compilateur
ET la même bibliothèque.)

Features : pendant longtemps, la STLPort était la seule implémentation
avec un mode debug. Même aujourd'hui, je crois qu'il n'y a que la
STLPort et Dinkumware qui l'ont. C'est un argument très fort en
faveur d'une de ces bibliothèques.

Performances : je trouve que ce ne doit pas être une raison, mais
malheureusement, certaines bibliothèques (comme la version de Rogue
Wave qui vient avec Sun CC 5.1) sont tellement lentes que d'être
quasiment inutilisable.

J'imagine que tout ce qui est proposé (vu de l'extérieur) est pareil :
mêmes fonctionnalités, mêmes templates.

À quelques détails près. La plupart ont des extensions (comme hash_map),
et ces extensions ne sont pas forcément compatible. Mais la grande
différence, c'est la présence ou l'absense d'une mode debug.

Si tu fais du multi-thread, il faut voir aussi. Autant que je sache,
toutes les implémentations pour des environements multi-threaded reclame
le « thread safety », mais il y a au moins trois définitions différentes
de ce que « thread safe » signifie :

- G++ dit que c'est à l'utilisateur de protéger tous les accès dès
qu'on accède à l'objet depuis plus d'un thread. Y compris si tous
les accès sont uniquement en lecture. (C'est donc moins de garanties
que ce qu'on a pour un int, au moins sous Posix.)

- SGI et la STLPort font les mêmes garanties qu'on a pour un objet de
type de base sous Posix : c'est à l'utilisateur de protéger tous les
accès dès qu'il y accès depuis plus d'un thread ET qu'au moins un
des threads peut modifier l'objet. Si tous les accès sont en lecture
seulement, il n'y a pas besoin de protection.

- Rogue Wave prend un lock dans chaque fonction, de façon qu'en
principe, l'utilisateur n'a jamais besoin de prendre un lock. Je dis
bien en principe, parce qu'évidemment, son lock ne s'étend pas au
delà de la fonction, et donc ne protège pas la référence renvoyée
par std::vector<>::operator[], par exemple.

Dans l'ensemble, je trouve que la troisième définition n'apporte rien
par rapport à la deuxième dans la pratique -- la granularité est trop
petite, et a un coût énorme en temps d'exécution. (Dans notre cas, une
facteur dix dans la performance totale du programme entre la
bibliothèque Rogue Wave livrée avec Sun CC et la STLPort. Ce qui est,
toujours dans notre cas, la différence entre une performance acceptable,
et une performance inacceptable.)

Je n'aime pas la définition utilisée par g++. Pas tellement qu'elle a un
défaut en soi (ça, on pourrait en discuter), mais surtout parce qu'elle
est différente que celle proposée généralement par le système pour les
types qu'il connaît. Si j'écris :

int const i = 42 ;
std::string const t( "abc" ) ;

Pourquoi est-ce qu'il me faut un lock pour chaque accès à t, quand il ne
m'en faut pas pour les accès à i ?

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Fabien LE LEZ

22/11/2003 à 03:26

On 20 Nov 2003 16:58:50 +0100, Jean-Marc Bourguet
wrote:

La norme adoptee en 1998
comprend une bibliotheque standard dont une partie est une adaptation
d'une partie de la bibliotheque de Stepanov et Lee appelee STL

Qu'y a-t-il dans la bibliothèque de Stepanov et Lee qui n'a pas été
repris dans la bibliothèque standard ?

--
;-)

Michel Michaud

22/11/2003 à 05:30

Dans news:, Fabien LE

On 20 Nov 2003 16:58:50 +0100, Jean-Marc Bourguet
wrote:

La norme adoptee en 1998
comprend une bibliotheque standard dont une partie est une
adaptation d'une partie de la bibliotheque de Stepanov et Lee
appelee STL

Qu'y a-t-il dans la bibliothèque de Stepanov et Lee qui n'a pas été
repris dans la bibliothèque standard ?

Certains design douteux ? (on en a ajouté d'autres :-)

--
Michel Michaud
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/

Compilateur et STL

10 réponses

Veuillez sélectionner un problème