OVH Cloud OVH Cloud

VC7++ & STLPort

7 réponses
Avatar
Murlock
Bonjour,

J'ai commencé à utiliser STL et je suis bloqué lorsque j'essaye
d'utiliser les flux avec les indications de taille :

std::ostringstream stream;
std::string directory, dir_file;
stream << std::setw(5) << entier << ".png";
dir_file=stream.str();

malheurement, ça bloque à la compil sur le setw
est-ce que quelqu'un a eu le même problème ?

Bonne journée,
Michael

7 réponses

Avatar
Arnaud Debaene
Murlock wrote:
Bonjour,

J'ai commencé à utiliser STL et je suis bloqué lorsque j'essaye
d'utiliser les flux avec les indications de taille :

std::ostringstream stream;
std::string directory, dir_file;
stream << std::setw(5) << entier << ".png";
dir_file=stream.str();

malheurement, ça bloque à la compil sur le setw
est-ce que quelqu'un a eu le même problème ?



Quel est le message d'erreur? Est-ce que tu as bien #inclus <iomanip> ?

Arnaud
Avatar
Murlock
Arnaud Debaene wrote:




Quel est le message d'erreur? Est-ce que tu as bien #inclus <iomanip> ?

Arnaud






Honte sur moi ! je vais copier pour la peine 100 fois
'n'oublie pas <iomanip>'

Merci encore, ça m'avait complétement sorti de la tête vu que par défaut
le compilo essaye de se rabattre sur ces STL à lui (j'utilise
STLport), j'ai complètement zappé ça...

Désolé du derangement et encore merci
Michael
Avatar
Murlock
Arnaud Debaene wrote:
>>
>
> Quel est le message d'erreur? Est-ce que tu as bien #inclus <iomanip> ?
>
> Arnaud
>
>


Honte sur moi ! je vais copier pour la peine 100 fois
'n'oublie pas <iomanip>'

Merci encore, ça m'avait complétement sorti de la tête vu que par défaut
le compilo essaye de se rabattre sur ces STL à lui (j'utilise
STLport), j'ai complètement zappé ça...

Désolé du derangement et encore merci
Michael
Avatar
Arnaud Debaene
Murlock wrote:

Merci encore, ça m'avait complétement sorti de la tête vu que par
défaut le compilo essaye de se rabattre sur ces STL à lui (j'utilise
STLport), j'ai complètement zappé ça...



AMHA, c'est une *très* mauvaise idée de mélanger 2 implémentations de la STL
: Si tu tiens à utiliser STLPort, vires le répertoire de la STL de
Dinkumware (celle par défaut) de la liste des répertoires d'include du
compilateur.

Au fait, pour info, avec VC7, la STL livrée avec le compilo est plus
conforme que STLPort.

Arnaud
Avatar
Murlock
Arnaud Debaene wrote:
Murlock wrote:


Merci encore, ça m'avait complétement sorti de la tête vu que par
défaut le compilo essaye de se rabattre sur ces STL à lui (j'utilise
STLport), j'ai complètement zappé ça...




AMHA, c'est une *très* mauvaise idée de mélanger 2 implémentations de la STL
: Si tu tiens à utiliser STLPort, vires le répertoire de la STL de
Dinkumware (celle par défaut) de la liste des répertoires d'include du
compilateur.






Au fait, pour info, avec VC7, la STL livrée avec le compilo est plus
conforme que STLPort.



Donc l'intérêt d'utiliser STLport est très reduite ? Quelle est la
garantie qu'un compilo récent (VC7 / g++ / borland) ait le même
comportement vis à vis du STL ?

un fu sur fr.comp.lang.c++ s'impose peut-être ?


Merci pour ces informations
Avatar
Arnaud Debaene
Murlock wrote:

Donc l'intérêt d'utiliser STLport est très reduite ?


Ca dépend de ce que tu cherches. STLPort a 2 avantages AMHA :
- Elle portable sur pas mal de systèmes, donc si tu dois faire du code
portable, utiliser STLPort te garantit que tu est "bug-compatible" avec toi
même sur toutes les palts-formes cibles. Sauf cas tordu, ca me semble très
limité comme avantage.
- Elle offre pas mal de diagnostics en mode debug, par exemple la détection
de dépassement ou de mauvaise utilisation d'iterateurs; etc...

Par contre, elle est nettement moins conformante que celle de Dinkumware,
surtout en ce qui concerne les flux et les locales si je me souviens bien.

Quelle est la
garantie qu'un compilo récent (VC7 / g++ / borland) ait le même
comportement vis à vis du STL ?


Chacun essaie d'implémenter au mieux la norme mais dans l'absolu, tu n'as
aucune garantie que telle implémentation ne soit pas buggée sur le point
dont tu as besoin ;-)
Plus sérieusement, dans 95% des cas, les implémentations de ces 3
compilateurs sont équivalentes. AMHA, si tu pousses la STL dans ses
retranchements, c'et plutôt la conformance des compilateurs sur le code
template un peu tordu qui risque de poser problème (notamment Borland, qui
pour l'instant est plutôt en retard sur la question).

Arnaud
Avatar
Murlock
Arnaud Debaene wrote:

Murlock wrote:

Donc l'intérêt d'utiliser STLport est très reduite ?



Ca dépend de ce que tu cherches. STLPort a 2 avantages AMHA :
- Elle portable sur pas mal de systèmes, donc si tu dois faire du code
portable, utiliser STLPort te garantit que tu est "bug-compatible" avec toi
même sur toutes les palts-formes cibles. Sauf cas tordu, ca me semble très
limité comme avantage.



Merci, je laisse donc STLport de côté,

merci pour toutes ces infos

Cordialement,
Michael