Templates et portabilité

Le 28-08-2009, Christian PANEL <c.panel@free.fr> a écrit :

Si j'ai effectivement constaté avec des compilateurs aniens que les
templates posaient problème, je suis curieux de savoit actuellement quels
sont les écueils qui existent sur les templates entre différents
compilateurs. Avez vous des exemples précis de la non portabilité de codes
écrits avec les templates ? Si vous en avez constaté, est-il possible
d'écrire un code portable avec les templates et si oui quelles sont les
précautions à prendre pour assurer un maximum de portabilité.

Recadrons le sujet: tu parles bien d'utiliser la STL, pas
d'écrire tes propres templates ? Dans ce cas, je ne vois pas
quel pourrait être le souci de portabilité: chaque compilo
C++ est fournis avec une version de la STL, et arrive
à la compiler. Non ?

J'ai constaté également que le code écrit avec des templates de manière
assez poussé était d'une part assez illisible, et d'autre part difficilement
déboguable de par son manque de lisibilité et surtout de par les messages
souvent complètement incompréhensibles qu'envoient les compilateurs y
compris parfois pour de simples erreurs. Qu'en pensez-vous ? Faut-il bannir
les templates ? (dommage?)

Il y a des gens qui "jouent" avec les template. A mon sens, les templates
C++ ont ouvert de nouveaux paradigmes de programmation, et les usages
ne sont pas encore figés.

Je pense que si tu remplaces le mot "template" par le mot "objet",
tu retrouveras des inquiétudes que les programmeurs avaient il y a
15 ans...

Quand on commence avec les templates, en effet, il faut arriver
à sélectionner ses lectures, éviter les gens qui disent "regarder,
c'est super, on arrive même à faire des trucs comme ça", et commencer
par des usages moins entousiates, pragrammatiques, et utiles.

J'aimerais également avoir votre avis sur l'utilisation de la STL pour
développer un code portable.

Ben, justement, la STL étant la librairie standard, son principal
avantage sur ses concurents, c'est la portabilité.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0

On Aug 28, 11:13 am, "Christian PANEL" <c.pa...@free.fr> wrote:

Je developpe en C et C++ depuis plusieurs années avec des
Frameworks plus classiques sous windows (MFC et OWL) et essaye
de me mettre à la page notamment en étudiant la STL que je
n'utilisais pas.

En glanant des informations de ci de là, Je suis tombé sur des
affirmations qui semblent sérieuses (site de wxWindows) qui me
posent questions et sur lesquelles j'aimerais avoir des
précisions et l'avis de personnes éclairées
:
En effet on peut lire :
"[i]Templates

wxWidgets does not use templates (except for some advanced
features that are switched off by default) since it is a
notoriously unportable feature.[/i]"

Si j'ai effectivement constaté avec des compilateurs aniens
que les templates posaient problème, je suis curieux de savoit
actuellement quels sont les écueils qui existent sur les
templates entre différents compilateurs. Avez vous des
exemples précis de la non portabilité de codes écrits avec les
templates ? Si vous en avez constaté, est-il possible d'écrire
un code portable avec les templates et si oui quelles sont les
précautions à prendre pour assurer un maximum de portabilité.

Le gros problème est la recherche du nom. Les jours où certains
compilateurs ne supportaient pas de templates, ou en avaient un
support limité (pas de template membres) sont fini (au moins
qu'on t'oblige à utiliser un compilateur périmé, genre VC++ 6
ou Sun CC 4.1). Mais l'implémentation des noms dépendants et ces
effets de bord varie encore énormement.

Ce qui ne veux pas dire que tu ne peux pas utiliser des
templates dans le code portable. Si le template est bien écrit,
et il passe un compilateur moderne, il y a de fortes chances
qu'il fonctionne partout. La plupart des templates qui compile
avec des anciens compilateurs marchent aussi avec des nouveaux,
mais j'ai bien rencontré des exceptions (surtout dans le cas des
cycles dans les dépendences, c-à-d que template A utilise
template B dans son implémentation et vice versa).

J'ai constaté également que le code écrit avec des templates
de manière assez poussé était d'une part assez illisible, et
d'autre part difficilement déboguable de par son manque de
lisibilité et surtout de par les messages souvent complètement
incompréhensibles qu'envoient les compilateurs y compris
parfois pour de simples erreurs. Qu'en pensez-vous ?

Que c'est possible d'écrire du code illisible aussi bien sans
templates qu'avec. Ensuite, c'est à toi de juger ce qui est
lisible, et ce qui ne l'est pas, et d'éviter l'illisible.

Faut-il bannir les templates ? (dommage?)

Qu'est-ce que tu proposes d'alternatif ? Dans le temps avant
templates, je me suis bien servi de <generic.h>. Alors, si c'est
l'illisible que tu cherches...

J'aimerais également avoir votre avis sur l'utilisation de la
STL pour développer un code portable.

En général, une utilisation plus ou moins limitée de la STL ne
pose pas de problèmes. Le seul problème de portabilité que je
constate avec la STL, c'est que certains compilateurs livrent
encore des versions assez anciennes, qui datent d'avant le
support des membres template, et que du coup, tu ne peux pas
utiliser les membres template dans du code portable. Ce qui
touche surtout, au moins dans mon code, les constructeurs à deux
itérateurs ; à la place de :
std::vector< T > v( autreContainer.begin(),
autreContainer.end() ) ;
, il faut écrire :
std::vector< T > v ;
std::copy( autreContainer.begin(),
autreContainer.end(),
std::back_inserter( v ) ) ;

--
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

>> Faut-il bannir les templates ? (dommage?)

Qu'est-ce que tu proposes d'alternatif ? Dans le temps avant
templates, je me suis bien servi de <generic.h>. Alors, si c'est
l'illisible que tu cherches...

je me renseigne juste... Je n'ai jamais utilisé les templates qu'en
"surface" car utilisait des vieux compilos qui posaient pas mal de problèmes
avec (et ne supportaient pas tout un tas d'amélioration existant
actuellement) : pour ne pas le nommer j'utilisais BC 5.02

En général, une utilisation plus ou moins limitée de la STL ne
pose pas de problèmes. Le seul problème de portabilité que je
constate avec la STL, c'est que certains compilateurs livrent
encore des versions assez anciennes, qui datent d'avant le
support des membres template, et que du coup, tu ne peux pas
utiliser les membres template dans du code portable. Ce qui
touche surtout, au moins dans mon code, les constructeurs à deux
itérateurs ; à la place de :
std::vector< T > v( autreContainer.begin(),
autreContainer.end() ) ;
, il faut écrire :
std::vector< T > v ;
std::copy( autreContainer.begin(),
autreContainer.end(),
std::back_inserter( v ) ) ;

je ne voudrais pas paraitre ignare, mais suis un peu "à la traine" en ce qui
concerne les nouveautés (oui je sais 10 ans déjà!!), mais pourrais-tu
m'éclairer sur ce que tu appeles membres template ? et peut être comprendre
pourquoi la deuxième forme indiquée fonctionne mieux que la première ...

en tout cas merci !

"Marc Boyer" <Marc.Boyer@cert.onera.fr.invalid> a écrit dans le message de
news: h78bnm$lbm$1@news.cict.fr...

Recadrons le sujet: tu parles bien d'utiliser la STL, pas
d'écrire tes propres templates ? Dans ce cas, je ne vois pas
quel pourrait être le souci de portabilité: chaque compilo
C++ est fournis avec une version de la STL, et arrive
à la compiler. Non ?

je parle des deux !
deux versions de la STL ne sont pas obligées de fonctionner
identiquement...
en théorie oui, mais en pratique ? On peut dire alors que l'implémentation
alpha est une mauvaise implémentation et ne pas l'utiliser ou on peut se
dire "on attend encore quelques années que tout le monde se soit aligné"

Il y a des gens qui "jouent" avec les template. A mon sens, les
templates
C++ ont ouvert de nouveaux paradigmes de programmation, et les usages
ne sont pas encore figés.

oui, c'est sur, mais peut être est-ce du au fait que les templates ont eu du
mal justement d'une part à se "standardiser" et d'autre part à s'exempter de
nombreux bugs et illogismes, non ?

Je pense que si tu remplaces le mot "template" par le mot "objet",
tu retrouveras des inquiétudes que les programmeurs avaient il y a
15 ans...

tout concept nouveau demande un apprentissage et qui n'est pas forcément
sans douleur pour tout le monde, surtout quand le concept était pas trés
solide au départ.

Quand on commence avec les templates, en effet, il faut arriver
à sélectionner ses lectures, éviter les gens qui disent "regarder,
c'est super, on arrive même à faire des trucs comme ça", et commencer
par des usages moins entousiates, pragrammatiques, et utiles.

oui, c'est pour cela que j'essaie de repartir à zéro et de me refaire une
idée des possibilités offertes
(qui sont trés attrayantes)

Ben, justement, la STL étant la librairie standard, son principal
avantage sur ses concurents, c'est la portabilité.

entièrement d'accord

On Fri, 28 Aug 2009 11:13:07 +0200, "Christian PANEL"
<c.panel@free.fr>:

wxWidgets does not use templates

Quand le projet wxWidgets (wxWindows à l'époque) a démarré, les
compilateurs avaient quelques soucis avec les templates. Mais bon, on
parle là de 1992. Nous sommes maintenant en 2009.

"Christian PANEL" wrote:

En général, une utilisation plus ou moins limitée de la STL ne
pose pas de problèmes. Le seul problème de portabilité que je
constate avec la STL, c'est que certains compilateurs livrent
encore des versions assez anciennes, qui datent d'avant le
support des membres template, et que du coup, tu ne peux pas
utiliser les membres template dans du code portable.

Il y en a d'autres que Sun Studio qui ont ce problème ? (et encore, ce
compilateur vient avec 1 ou 2 autres implémentations de la bibliothèque
standard, qui elles sont standard)

Ce qui
touche surtout, au moins dans mon code, les constructeurs à deux
itérateurs ; à la place de :
std::vector< T > v( autreContainer.begin(),
autreContainer.end() ) ;
, il faut écrire :
std::vector< T > v ;
std::copy( autreContainer.begin(),
autreContainer.end(),
std::back_inserter( v ) ) ;

L'impossibilité de convertir les std::pair entre eux est pénible aussi
(l'avantage c'est qu'on n'utilise du coup jamais
map::insert(make_pair(a,b)) avec sa copie inutile).

je ne voudrais pas paraitre ignare, mais suis un peu "à la traine" en ce qui
concerne les nouveautés (oui je sais 10 ans déjà!!), mais pourrais-tu
m'éclairer sur ce que tu appeles membres template ? et peut être comprendre
pourquoi la deuxième forme indiquée fonctionne mieux que la première ...

Une fonction membre, c'est une fonction déclarée dans la classe, qui a
implicitement comme argument this, et s'appelle généralement de
l'extérieur par objet.fonction(args). Une fonction template, c'est une
fonction qui dépend d'un paramètre template. Donc la on parle des
fonctions qui sont les 2 à la fois :
template<...> class vector {
template<typename InputIterator> vector(InputIterator premier,
InputIterator fin); // constructeur template
};

Certains compilateurs ont implémenté ça avec un peu de retard et ont donc
livré des bibliothèques "standard" privées de cette fonction. Par crainte
de créer des incompatibilités au niveau de l'ABI, ils n'ont pas rajouté
après coup ces fonctions, même quand le compilateur a appris à les gérer.

std::copy dans l'exemple ci-dessus est une fonction template, mais pas
membre d'une classe, donc elle ne pose aucun problème.

Mais vraiment, je te recommande d'ignorer ce problème, à moins d'avoir un
très fort impératif à court terme de développer pour une plate-forme
particulière ayant ce problème.

Pour écrire du code portable, tester reste une des meilleures solutions.
MSVC, g++ et un compilateur utilisant EDG (Intel par exemple) forment un
échantillon raisonnable. Rajouter Sun Studio (-library=stlport4) sur
Solaris permet de détecter les problèmes de std:: et extern "C", et
fournit aussi un exemple d'implémentation où vector::iterator est un
pointeur (donc pas de --v.end(), merci) ; malheureusement il vient aussi
avec un peu plus de bugs que les 3 autres.

On Aug 28, 4:57 pm, "Christian PANEL" <c.pa...@free.fr> wrote:

> En général, une utilisation plus ou moins limitée de la STL
> ne pose pas de problèmes. Le seul problème de portabilité
> que je constate avec la STL, c'est que certains compilateurs
> livrent encore des versions assez anciennes, qui datent
> d'avant le support des membres template, et que du coup, tu
> ne peux pas utiliser les membres template dans du code
> portable. Ce qui touche surtout, au moins dans mon code, les
> constructeurs à deux itérateurs ; à la place de :
> std::vector< T > v( autreContainer.begin(),
> autreContainer.end() ) ;
> , il faut écrire :
> std::vector< T > v ;
> std::copy( autreContainer.begin(),
> autreContainer.end(),
> std::back_inserter( v ) ) ;

je ne voudrais pas paraitre ignare, mais suis un peu "à la
traine" en ce qui concerne les nouveautés (oui je sais 10 ans
déjà!!), mais pourrais-tu m'éclairer sur ce que tu appeles
membres template ?

Ce sont des fonctions templatées membre d'une classe ou d'un
template de classe. Dans la spécification initiale des templates
(dans l'ARM) et dans les implémentations initiales, il n'y avait
pas de templates membres ; tous les templates devaient être
spécifiés à la portée de fichier (ou d'éspace référentiel, pl us
tard).

et peut être comprendre pourquoi la deuxième forme indiquée
fonctionne mieux que la première ...

Parce que dans le cas de la première, la « fonction » invoquée,
c'est le constructeur templaté, qui n'existait évidemment pas
avant les templates membres. Tandis que dans la seconde, c'est
la fonction templatée globale std::copy qui sert.

--
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 Aug 29, 7:03 am, Marc <marc.gli...@gmail.com> wrote:

"Christian PANEL" wrote:
>> En général, une utilisation plus ou moins limitée de la STL
>> ne pose pas de problèmes. Le seul problème de portabilité
>> que je constate avec la STL, c'est que certains
>> compilateurs livrent encore des versions assez anciennes,
>> qui datent d'avant le support des membres template, et que
>> du coup, tu ne peux pas utiliser les membres template dans
>> du code portable.

Il y en a d'autres que Sun Studio qui ont ce problème ? (et
encore, ce compilateur vient avec 1 ou 2 autres
implémentations de la bibliothèque standard, qui elles sont
standard)

Je n'en sais rien, mais Sun CC, c'est bien un compilateur
répandu et important. Et oui, il vient avec une version de la
STLport, aussi. Mais celle-ci est tellement boguée qu'elle est
inutilisable. Tu peux facilement écrire autour de quelque chose
qui manque -- après tous, tu écrivais bien des programmes avant
qu'il a été ajouté ailleurs. Mais certains bogues sont carrément
incontournable, et rend des pans entiers de la bibliothèque
(comme <locale>) complètement inutilisable.

Il y aussi VC++ 6. Périmé, certes, mais il sert encore à
certains endroits.

La question finale, évidemment, c'est jusqu'à où pousser la
portabilité. Si des versions relativement récentes de g++ et de
VC++ te suffisent, ce n'est pas un problème.

>> Ce qui
>> touche surtout, au moins dans mon code, les constructeurs à deux
>> itérateurs ; à la place de :
>> std::vector< T > v( autreContainer.begin(),
>> autreContainer.end() ) ;
>> , il faut écrire :
>> std::vector< T > v ;
>> std::copy( autreContainer.begin(),
>> autreContainer.end(),
>> std::back_inserter( v ) ) ;

L'impossibilité de convertir les std::pair entre eux est
pénible aussi (l'avantage c'est qu'on n'utilise du coup jamais
map::insert(make_pair(a,b)) avec sa copie inutile).

C'est marrant ; je ne crois pas d'avoir eu des problèmes à cet
égard. Mais il faut dire que j'ai toujours privilégé le style :
unMap.insert( MapType::value_type( cle, valeur ) ) ;
sur le make_pair. (Je ne sais pas pourquoi, d'ailleurs, mais tu
viens de m'en donner une raison de plus.)

[...]
[en ce concerne les fonctions membre...]

Certains compilateurs ont implémenté ça avec un peu de retard

Il ne faut pas oublier que la première spécification des
templates (dans l'ARM) ne comportait pas de templates membres,
et que la première implémentation (souvent citée comme
implémentation de référence), CFront 3.0, non plus. Les
templates membres sont une innovation du comité, peut-être assez
tardive même (mais je ne sais pas exactement quand le comité les
a introduits).

et ont donc livré des bibliothèques "standard" privées de
cette fonction.

La STL original, proposée au comité, ne s'en servait pas, parce
que les compilateurs dont se servait l'auteur à l'époque ne les
supportaient pas.

Par crainte de créer des incompatibilités au niveau de l'ABI,
ils n'ont pas rajouté après coup ces fonctions, même quand le
compilateur a appris à les gérer.

L'histoire chez Sun est encore plus compliqué, je crois ; en
tout cas, la version de la bibliothèque Rogue Wave dont se sert
le compilateur par défaut est fort ancienne.

[...]

Mais vraiment, je te recommande d'ignorer ce problème, à moins
d'avoir un très fort impératif à court terme de développer
pour une plate-forme particulière ayant ce problème.

Je ne suis pas sûr, mais je crois que dès qu'on sort du monde
des PC (Windows, Linux et Mac), Sun CC est le compilateur le
plus répandu. C'est au moins celui que je vois le plus.

Éviter le problème, en revanche, si on n'a pas de compilateur
qui le présente, c'est assez difficile. On finit par se servir
d'un template membre standard sans toujours s'en rendre compte.
(De l'autre côté, chaque fois que ça m'est arrivé, une
réécriture comme dans mon exemple s'est avérée assez triviale.)

Pour écrire du code portable, tester reste une des meilleures
solutions. MSVC, g++ et un compilateur utilisant EDG (Intel
par exemple) forment un échantillon raisonnable.

Si tu vises la portabilité maximum, pas vraiment, parce qu'ils
sont tous les trois assez à jour, et à l'exception d'export,
assez proche de la norme. Or, si tu vises la portabilité, il te
faut des anciens compilateurs, ou ceux qui n'implémente pas
encore toutes les nouveautés.

Rajouter Sun Studio (-library=stlport4) sur Solaris permet de
détecter les problèmes de std:: et extern "C", et fournit
aussi un exemple d'implémentation où vector::iterator est un
pointeur (donc pas de --v.end(), merci) ; malheureusement il
vient aussi avec un peu plus de bugs que les 3 autres.

Un peu plus, c'est peu dire. En ce qui concerne les collections
et les algorithmes, ça va encore, mais les iostream et les
locales sont quasiment inutilisable.

Il y a aussi le problème de pourquoi tu veux être portable. Dans
la pratique, sous Solaris, on utilise g++, plutôt que Sun CC, si
on peut. Seulement, très souvent, on doit linké avec des
bibliothèques tièrces, qui sont la plupart du temps livrées
seulement en version Sun CC, avec la bibliothèque Sun par
défaut. Dans la pratique, je n'ai jamais connu un contexte
professionnel où Sun CC plus STLport avait un sens.

--
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

merci, un coin de ciel bleu se découvre pour moi ! ;o)

James Kanze wrote:

Je n'en sais rien, mais Sun CC, c'est bien un compilateur
répandu et important. Et oui, il vient avec une version de la
STLport, aussi. Mais celle-ci est tellement boguée qu'elle est
inutilisable.

?
Dans mon expérience, il manque plein de choses dans Cstd, mais stlport4
fonctionne bien.

Tu peux facilement écrire autour de quelque chose
qui manque -- après tous, tu écrivais bien des programmes avant
qu'il a été ajouté ailleurs. Mais certains bogues sont carrément
incontournable, et rend des pans entiers de la bibliothèque
(comme <locale>) complètement inutilisable.

Tu fais référence au fait que "C" est la seule locale supportée par
stlport4 ? C'est effectivement un problème.

Il y aussi VC++ 6. Périmé, certes, mais il sert encore à
certains endroits.

Pitié pour le programmeur...

La question finale, évidemment, c'est jusqu'à où pousser la
portabilité. Si des versions relativement récentes de g++ et de
VC++ te suffisent, ce n'est pas un problème.

Ça suffit quand même dans beaucoup de cas.

L'impossibilité de convertir les std::pair entre eux est
pénible aussi (l'avantage c'est qu'on n'utilise du coup jamais
map::insert(make_pair(a,b)) avec sa copie inutile).

C'est marrant ; je ne crois pas d'avoir eu des problèmes à cet
égard. Mais il faut dire que j'ai toujours privilégé le style :
unMap.insert( MapType::value_type( cle, valeur ) ) ;
sur le make_pair. (Je ne sais pas pourquoi, d'ailleurs, mais tu
viens de m'en donner une raison de plus.)

Note qu'en C++0X la copie inutile disparaît, au moins... (enfin je crois)

[en ce concerne les fonctions membre...]

Certains compilateurs ont implémenté ça avec un peu de retard

Il ne faut pas oublier que la première spécification des
templates (dans l'ARM) ne comportait pas de templates membres,

Je suis trop jeune ;-)

Par crainte de créer des incompatibilités au niveau de l'ABI,
ils n'ont pas rajouté après coup ces fonctions, même quand le
compilateur a appris à les gérer.

L'histoire chez Sun est encore plus compliqué, je crois ; en
tout cas, la version de la bibliothèque Rogue Wave dont se sert
le compilateur par défaut est fort ancienne.

Elle est ancienne (avec un certain nombre de patchs backportés), mais
elle a en gros toutes les fonctionnalités. Elles sont juste désactivées
par un jeu de macros.

Pour écrire du code portable, tester reste une des meilleures
solutions. MSVC, g++ et un compilateur utilisant EDG (Intel
par exemple) forment un échantillon raisonnable.

Si tu vises la portabilité maximum, pas vraiment, parce qu'ils
sont tous les trois assez à jour, et à l'exception d'export,
assez proche de la norme. Or, si tu vises la portabilité, il te
faut des anciens compilateurs, ou ceux qui n'implémente pas
encore toutes les nouveautés.

L'OP semblait viser une portabilité raisonnable mais pas maximale. En
commençant un développement maintenant, les compilateurs les plus
antiques auront presque le temps de disparaître. (je suis complètement
d'accord avec toi si on cherche une portabilité maximale, je pense juste
que c'est une contrainte qu'il ne faut pas s'imposer sans une excellente
raison)

Rajouter Sun Studio (-library=stlport4) sur Solaris permet de
détecter les problèmes de std:: et extern "C", et fournit
aussi un exemple d'implémentation où vector::iterator est un
pointeur (donc pas de --v.end(), merci) ; malheureusement il
vient aussi avec un peu plus de bugs que les 3 autres.

Un peu plus, c'est peu dire. En ce qui concerne les collections
et les algorithmes, ça va encore, mais les iostream et les
locales sont quasiment inutilisable.

Les locales : stlport4 n'a que "C" et Cstd supporte mal le multi-thread,
mais pour iostream, je suis surpris, je ne me souviens pas de problème
particulier avec stlport4.

Il y a aussi le problème de pourquoi tu veux être portable. Dans
la pratique, sous Solaris, on utilise g++, plutôt que Sun CC, si
on peut. Seulement, très souvent, on doit linké avec des
bibliothèques tièrces, qui sont la plupart du temps livrées
seulement en version Sun CC, avec la bibliothèque Sun par
défaut. Dans la pratique, je n'ai jamais connu un contexte
professionnel où Sun CC plus STLport avait un sens.

Sur sparc, on évite le backend de gcc si on peut, pour des raisons de
performance évidentes. Ça peut vouloir dire utiliser gccfss (front-end
gcc, back-end Sun Studio), mais c'est un produit assez marginal, et avec
des perspectives d'avenir limitées pour des raisons de licence à partir
de gcc-4.4. Sinon, c'est Sun Studio. En l'absence de bibliothèques
tièrces binaires liées à Cstd, il est beaucoup plus facile de porter un
code C++ standard à stlport4 (ça va probablement juste marcher) qu'à
Cstd, et les performances sont souvent meilleures.

Dans une perspective d'avenir, Opensolaris intègre actuellement la
libstdcxx d'Apache (=Roguewave moderne) qui sera la bibliothèque standard
C++ par défaut dans Solaris, et est recommandée par les développeurs de
Sun Studio aux gens qui postent dans les forums pour des problèmes avec
Cstd/stlport4.