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.
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 :
Bonjour,
tu as l'air de connaitres les implications de multi-thread avec la STL...
la STLPort implemente-t-elle des méthodes lock() et unlock() ? ou est-ce à l'utilisateur de mettre en place ces mécanismes en fonction de la plateforme ? Qu'en est-il avec a STL g++ ? visual ?
cordialement,
Mathieu
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 :
Bonjour,
tu as l'air de connaitres les implications de multi-thread avec la STL...
la STLPort implemente-t-elle des méthodes lock() et unlock() ? ou est-ce
à l'utilisateur de mettre en place ces mécanismes en fonction de la
plateforme ?
Qu'en est-il avec a STL g++ ? visual ?
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 :
Bonjour,
tu as l'air de connaitres les implications de multi-thread avec la STL...
la STLPort implemente-t-elle des méthodes lock() et unlock() ? ou est-ce à l'utilisateur de mettre en place ces mécanismes en fonction de la plateforme ? Qu'en est-il avec a STL g++ ? visual ?
cordialement,
Mathieu
Michel Michaud
Dans news:bpih5r$c5s$, Marc
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.
Pas dans std. En tout cas, pas avec des noms non réservés (avec les __ par exemple).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:bpih5r$c5s$2@news.cict.fr, Marc
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.
Pas dans std. En tout cas, pas avec des noms non réservés (avec
les __ par exemple).
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
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.
Pas dans std. En tout cas, pas avec des noms non réservés (avec les __ par exemple).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
James Kanze
Mathieu Peyréga writes:
|> > 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 :
|> tu as l'air de connaitres les implications de multi-thread avec la |> STL...
Oui et non. J'en ai discuté des buts avec Matt Austern, dans le temps. J'ai aussi eu des problèmes dans l'implémentation g++ (de std::string, qui historiquement ne fait pas partie de la STL).
|> la STLPort implemente-t-elle des méthodes lock() et unlock() ?
Pas à ce que je sache. Mais est-ce qu'elle doit les implémenter ? Ce sont plutôt des fonctions de l'API de la plateforme, je crois.
|> ou est-ce à l'utilisateur de mettre en place ces mécanismes en |> fonction de la plateforme ?
|> Qu'en est-il avec a STL g++ ? visual ?
La STLPort se base sur l'implémentation SGI ; tu peux bien lire comment fait l'implémentation SGI sur leur site. En gros, ils garantissent ce que garantit Posix pour les types de base. C-à-d que si l'utilisateur utilise un objet dans un thread, et un autre objet dans un autre thread, il n'y aura pas de problème. De même si tous les accès sont en lecture. Sinon, c'est à l'utilisateur de s'assurer la synchronisation. Soit au moyen des requêtes de base propre au système, soit au moyen d'une bibliothèque plus ou moin portable, comme celle de Boost.
La partie proprement STL de g++ dérive aussi de SGI, et donne donc les mêmes garanties. La reste de la bibliothèque g++ donne des garanties encore plus faible -- dès qu'un objet est visible dans plus d'un fils (même s'il n'y a pas d'écriture), il faut utiliser une synchronisation externe. (Et attention ici : le std::basic_string ne dérive pas de l'implémentation SGI.)
Quand à VC++, aucune idée. VC++ a un défaut majeur en ce qui me concerne -- son code généré ne fonctionne pas sur des plateformes qui m'intéressent (principalement Sparc sous Solaris actuellement).
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> > 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 :
|> tu as l'air de connaitres les implications de multi-thread avec la
|> STL...
Oui et non. J'en ai discuté des buts avec Matt Austern, dans le
temps. J'ai aussi eu des problèmes dans l'implémentation g++ (de
std::string, qui historiquement ne fait pas partie de la STL).
|> la STLPort implemente-t-elle des méthodes lock() et unlock() ?
Pas à ce que je sache. Mais est-ce qu'elle doit les implémenter ?
Ce sont plutôt des fonctions de l'API de la plateforme, je crois.
|> ou est-ce à l'utilisateur de mettre en place ces mécanismes en
|> fonction de la plateforme ?
|> Qu'en est-il avec a STL g++ ? visual ?
La STLPort se base sur l'implémentation SGI ; tu peux bien lire
comment fait l'implémentation SGI sur leur site. En gros, ils
garantissent ce que garantit Posix pour les types de base. C-à-d que
si l'utilisateur utilise un objet dans un thread, et un autre objet dans
un autre thread, il n'y aura pas de problème. De même si tous les
accès sont en lecture. Sinon, c'est à l'utilisateur de s'assurer
la synchronisation. Soit au moyen des requêtes de base propre au
système, soit au moyen d'une bibliothèque plus ou moin portable,
comme celle de Boost.
La partie proprement STL de g++ dérive aussi de SGI, et donne donc
les mêmes garanties. La reste de la bibliothèque g++ donne des
garanties encore plus faible -- dès qu'un objet est visible dans plus
d'un fils (même s'il n'y a pas d'écriture), il faut utiliser une
synchronisation externe. (Et attention ici : le std::basic_string ne
dérive pas de l'implémentation SGI.)
Quand à VC++, aucune idée. VC++ a un défaut majeur en ce qui me
concerne -- son code généré ne fonctionne pas sur des
plateformes qui m'intéressent (principalement Sparc sous Solaris
actuellement).
--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
|> > 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 :
|> tu as l'air de connaitres les implications de multi-thread avec la |> STL...
Oui et non. J'en ai discuté des buts avec Matt Austern, dans le temps. J'ai aussi eu des problèmes dans l'implémentation g++ (de std::string, qui historiquement ne fait pas partie de la STL).
|> la STLPort implemente-t-elle des méthodes lock() et unlock() ?
Pas à ce que je sache. Mais est-ce qu'elle doit les implémenter ? Ce sont plutôt des fonctions de l'API de la plateforme, je crois.
|> ou est-ce à l'utilisateur de mettre en place ces mécanismes en |> fonction de la plateforme ?
|> Qu'en est-il avec a STL g++ ? visual ?
La STLPort se base sur l'implémentation SGI ; tu peux bien lire comment fait l'implémentation SGI sur leur site. En gros, ils garantissent ce que garantit Posix pour les types de base. C-à-d que si l'utilisateur utilise un objet dans un thread, et un autre objet dans un autre thread, il n'y aura pas de problème. De même si tous les accès sont en lecture. Sinon, c'est à l'utilisateur de s'assurer la synchronisation. Soit au moyen des requêtes de base propre au système, soit au moyen d'une bibliothèque plus ou moin portable, comme celle de Boost.
La partie proprement STL de g++ dérive aussi de SGI, et donne donc les mêmes garanties. La reste de la bibliothèque g++ donne des garanties encore plus faible -- dès qu'un objet est visible dans plus d'un fils (même s'il n'y a pas d'écriture), il faut utiliser une synchronisation externe. (Et attention ici : le std::basic_string ne dérive pas de l'implémentation SGI.)
Quand à VC++, aucune idée. VC++ a un défaut majeur en ce qui me concerne -- son code généré ne fonctionne pas sur des plateformes qui m'intéressent (principalement Sparc sous Solaris actuellement).
-- James Kanze mailto: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93
