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
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
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...
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
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
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...
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
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
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.
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
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
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 ?
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
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
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).
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
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
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.
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.