compilateurs avaient quelques soucis avec les templates. Mais bon, on
parle là de 1992. Nous sommes maintenant en 2009.
compilateurs avaient quelques soucis avec les templates. Mais bon, on
parle là de 1992. Nous sommes maintenant en 2009.
compilateurs avaient quelques soucis avec les templates. Mais bon, on
parle là de 1992. Nous sommes maintenant en 2009.
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...]
>> 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.
> 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.
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...]
>> 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.
> 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.
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...]
>> 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.
> 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.
"Marc Boyer" a écrit dans le message de
news: h78bnm$lbm$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 ?
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)
"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 ?
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)
"Marc Boyer" a écrit dans le message de
news: h78bnm$lbm$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 ?
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)
Le 28-08-2009, Christian PANEL a écrit :
Heuh... Il peut toujours rester des bugs partout, mais en 2009,
la STL, elle me paraît bien stable et connue et implantée.
Oui, on peut aussi travailler en ASM 8086 en se méfiant de tous
ses langages modernes et aux compilos bugées que sont C, Fortran, Lisp.
(je n'évoque même pas ses trucs de jeunes fous que sont Java, C++,
Ada...)
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 ?
A mon sens, c'est surtout du au fait que quand arrive un nouvel outil,
on ne sait pas bien comment l'utiliser. Les "Design Pattern" sont par
exemple des guides d'usage de l'OO.
Je vais revenir sur deux choses distinctes: utiliser la STL et
développer ses propres templates.
Utiliser la STL ne me semble pas bien compliqué (une fois compris
le principe d'itérateur et d'objet fonction -- operator() ), et quand
même bien utile. C'est à mon sens ce que tout dévelopeur C++ formé
de nos jours devrait savoir en sortant de l'école.
En fait, c'est utiliser autre chose que la STL qui demande justification.
Développer ses propres template demande plus de lecture et d'expérience.
Je manque d'expérience pour en parler. Mes propres classes template
m'ont beaucoup appris, mais ne sauraient passer en usage pour d'autres.
Le 28-08-2009, Christian PANEL <c.panel@free.fr> a écrit :
Heuh... Il peut toujours rester des bugs partout, mais en 2009,
la STL, elle me paraît bien stable et connue et implantée.
Oui, on peut aussi travailler en ASM 8086 en se méfiant de tous
ses langages modernes et aux compilos bugées que sont C, Fortran, Lisp.
(je n'évoque même pas ses trucs de jeunes fous que sont Java, C++,
Ada...)
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 ?
A mon sens, c'est surtout du au fait que quand arrive un nouvel outil,
on ne sait pas bien comment l'utiliser. Les "Design Pattern" sont par
exemple des guides d'usage de l'OO.
Je vais revenir sur deux choses distinctes: utiliser la STL et
développer ses propres templates.
Utiliser la STL ne me semble pas bien compliqué (une fois compris
le principe d'itérateur et d'objet fonction -- operator() ), et quand
même bien utile. C'est à mon sens ce que tout dévelopeur C++ formé
de nos jours devrait savoir en sortant de l'école.
En fait, c'est utiliser autre chose que la STL qui demande justification.
Développer ses propres template demande plus de lecture et d'expérience.
Je manque d'expérience pour en parler. Mes propres classes template
m'ont beaucoup appris, mais ne sauraient passer en usage pour d'autres.
Le 28-08-2009, Christian PANEL a écrit :
Heuh... Il peut toujours rester des bugs partout, mais en 2009,
la STL, elle me paraît bien stable et connue et implantée.
Oui, on peut aussi travailler en ASM 8086 en se méfiant de tous
ses langages modernes et aux compilos bugées que sont C, Fortran, Lisp.
(je n'évoque même pas ses trucs de jeunes fous que sont Java, C++,
Ada...)
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 ?
A mon sens, c'est surtout du au fait que quand arrive un nouvel outil,
on ne sait pas bien comment l'utiliser. Les "Design Pattern" sont par
exemple des guides d'usage de l'OO.
Je vais revenir sur deux choses distinctes: utiliser la STL et
développer ses propres templates.
Utiliser la STL ne me semble pas bien compliqué (une fois compris
le principe d'itérateur et d'objet fonction -- operator() ), et quand
même bien utile. C'est à mon sens ce que tout dévelopeur C++ formé
de nos jours devrait savoir en sortant de l'école.
En fait, c'est utiliser autre chose que la STL qui demande justification.
Développer ses propres template demande plus de lecture et d'expérience.
Je manque d'expérience pour en parler. Mes propres classes template
m'ont beaucoup appris, mais ne sauraient passer en usage pour d'autres.
"Marc Boyer" a écrit dans le message de
news: h7g4j7$tl6$Le 28-08-2009, Christian PANEL a écrit :
Heuh... Il peut toujours rester des bugs partout, mais en 2009,
la STL, elle me paraît bien stable et connue et implantée.
merci, c'est ce que je voulais savoir de personnes ayant l'habitude de
l'utiliser
Oui, on peut aussi travailler en ASM 8086 en se méfiant de tous
ses langages modernes et aux compilos bugées que sont C, Fortran, Lisp.
(je n'évoque même pas ses trucs de jeunes fous que sont Java, C++,
Ada...)
oui :o) ... non, ce que je voulais dire c'est que j'ai une approche assez
pragmatique, et calcule d'une part le temps d'apprentissage de "nouvelles"
technologies face au temps gagné grace à ces nouvelles technologies.
Typiquement pour donner un exemple : le cas des IDE qui font tout soit
disant trés bien et qui oblige l'utilisateur à passer un temps
incommensurable à déboguer ces derniers ou à apprendre toutes les limites du
système quand une ligne de commande, certes un peu plus lente et moins
pratique, mais plus sure, eut suffit.
Je commence seulement depuis quelques semaines à me lancer dans la STL parce
que je me dis qu'il faut quand même que je m'y mette mais me rends compte
que ca ne va pas être aussi rapide que cela et que je vais devoir mettre une
série de garde fous au cas ou la STL ne réagisse pas comme je l'ai escompté
au départ : il m'est indiqpensable de créer des objets créés/gérés par
plusieurs container et donc de manière indirecte => au moins un foncteur
pour la comparaison pour chaque container, peut être une gestion d'objets
partagés par compteurs : bref ce n'est pas simple et pas sans risque pour
celui qui ne connait pas la STL au départ et je me pose la question de son
avantage face à des structures de containers complexes (et obligatoirement
d'objets indirects).
Bref, si je me lance dedans c'est plus par gout de connaitre cette
biblithèque que par espoir de gagner du temps...
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 ?
A mon sens, c'est surtout du au fait que quand arrive un nouvel outil,
on ne sait pas bien comment l'utiliser. Les "Design Pattern" sont par
exemple des guides d'usage de l'OO.
je suis d'accord avec toi, je "connais" la bibliothèque depuis peu mais peut
me rendre compte que pour quelqu'un la connaissant trés bien, elle peut
apporter je pense de la rapidité de programmation et d'éxécution,
Reste à voir si elle ne contient pas trop
de "quirks" pour me la rendre moins sympathique qu'une bibliothèque dédiée à
mon application mon généraliste mais plus lisible, déboguable (et peut être
plus efficace)
Mais je n'aurai une réponse qu'après une grande habitude et pratique de
cette bibliothèque qui comme le disait je ne sais plus qui a le gros
avantage de porter le nom "standard".
En fait, c'est utiliser autre chose que la STL qui demande justification.
.. ou developper des structures complexes de containers par la STL me semble
t-il...
Développer ses propres template demande plus de lecture et d'expérience.
Je manque d'expérience pour en parler. Mes propres classes template
m'ont beaucoup appris, mais ne sauraient passer en usage pour d'autres.
en tout cas merci pour ton point de vue qui me permet avec d'autres de me
faire une idée sur ce que je peux attendre de celle-ci.
"Marc Boyer" <Marc.Boyer@cert.onera.fr.invalid> a écrit dans le message de
news: h7g4j7$tl6$1@news.cict.fr...
Le 28-08-2009, Christian PANEL <c.panel@free.fr> a écrit :
Heuh... Il peut toujours rester des bugs partout, mais en 2009,
la STL, elle me paraît bien stable et connue et implantée.
merci, c'est ce que je voulais savoir de personnes ayant l'habitude de
l'utiliser
Oui, on peut aussi travailler en ASM 8086 en se méfiant de tous
ses langages modernes et aux compilos bugées que sont C, Fortran, Lisp.
(je n'évoque même pas ses trucs de jeunes fous que sont Java, C++,
Ada...)
oui :o) ... non, ce que je voulais dire c'est que j'ai une approche assez
pragmatique, et calcule d'une part le temps d'apprentissage de "nouvelles"
technologies face au temps gagné grace à ces nouvelles technologies.
Typiquement pour donner un exemple : le cas des IDE qui font tout soit
disant trés bien et qui oblige l'utilisateur à passer un temps
incommensurable à déboguer ces derniers ou à apprendre toutes les limites du
système quand une ligne de commande, certes un peu plus lente et moins
pratique, mais plus sure, eut suffit.
Je commence seulement depuis quelques semaines à me lancer dans la STL parce
que je me dis qu'il faut quand même que je m'y mette mais me rends compte
que ca ne va pas être aussi rapide que cela et que je vais devoir mettre une
série de garde fous au cas ou la STL ne réagisse pas comme je l'ai escompté
au départ : il m'est indiqpensable de créer des objets créés/gérés par
plusieurs container et donc de manière indirecte => au moins un foncteur
pour la comparaison pour chaque container, peut être une gestion d'objets
partagés par compteurs : bref ce n'est pas simple et pas sans risque pour
celui qui ne connait pas la STL au départ et je me pose la question de son
avantage face à des structures de containers complexes (et obligatoirement
d'objets indirects).
Bref, si je me lance dedans c'est plus par gout de connaitre cette
biblithèque que par espoir de gagner du temps...
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 ?
A mon sens, c'est surtout du au fait que quand arrive un nouvel outil,
on ne sait pas bien comment l'utiliser. Les "Design Pattern" sont par
exemple des guides d'usage de l'OO.
je suis d'accord avec toi, je "connais" la bibliothèque depuis peu mais peut
me rendre compte que pour quelqu'un la connaissant trés bien, elle peut
apporter je pense de la rapidité de programmation et d'éxécution,
Reste à voir si elle ne contient pas trop
de "quirks" pour me la rendre moins sympathique qu'une bibliothèque dédiée à
mon application mon généraliste mais plus lisible, déboguable (et peut être
plus efficace)
Mais je n'aurai une réponse qu'après une grande habitude et pratique de
cette bibliothèque qui comme le disait je ne sais plus qui a le gros
avantage de porter le nom "standard".
En fait, c'est utiliser autre chose que la STL qui demande justification.
.. ou developper des structures complexes de containers par la STL me semble
t-il...
Développer ses propres template demande plus de lecture et d'expérience.
Je manque d'expérience pour en parler. Mes propres classes template
m'ont beaucoup appris, mais ne sauraient passer en usage pour d'autres.
en tout cas merci pour ton point de vue qui me permet avec d'autres de me
faire une idée sur ce que je peux attendre de celle-ci.
"Marc Boyer" a écrit dans le message de
news: h7g4j7$tl6$Le 28-08-2009, Christian PANEL a écrit :
Heuh... Il peut toujours rester des bugs partout, mais en 2009,
la STL, elle me paraît bien stable et connue et implantée.
merci, c'est ce que je voulais savoir de personnes ayant l'habitude de
l'utiliser
Oui, on peut aussi travailler en ASM 8086 en se méfiant de tous
ses langages modernes et aux compilos bugées que sont C, Fortran, Lisp.
(je n'évoque même pas ses trucs de jeunes fous que sont Java, C++,
Ada...)
oui :o) ... non, ce que je voulais dire c'est que j'ai une approche assez
pragmatique, et calcule d'une part le temps d'apprentissage de "nouvelles"
technologies face au temps gagné grace à ces nouvelles technologies.
Typiquement pour donner un exemple : le cas des IDE qui font tout soit
disant trés bien et qui oblige l'utilisateur à passer un temps
incommensurable à déboguer ces derniers ou à apprendre toutes les limites du
système quand une ligne de commande, certes un peu plus lente et moins
pratique, mais plus sure, eut suffit.
Je commence seulement depuis quelques semaines à me lancer dans la STL parce
que je me dis qu'il faut quand même que je m'y mette mais me rends compte
que ca ne va pas être aussi rapide que cela et que je vais devoir mettre une
série de garde fous au cas ou la STL ne réagisse pas comme je l'ai escompté
au départ : il m'est indiqpensable de créer des objets créés/gérés par
plusieurs container et donc de manière indirecte => au moins un foncteur
pour la comparaison pour chaque container, peut être une gestion d'objets
partagés par compteurs : bref ce n'est pas simple et pas sans risque pour
celui qui ne connait pas la STL au départ et je me pose la question de son
avantage face à des structures de containers complexes (et obligatoirement
d'objets indirects).
Bref, si je me lance dedans c'est plus par gout de connaitre cette
biblithèque que par espoir de gagner du temps...
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 ?
A mon sens, c'est surtout du au fait que quand arrive un nouvel outil,
on ne sait pas bien comment l'utiliser. Les "Design Pattern" sont par
exemple des guides d'usage de l'OO.
je suis d'accord avec toi, je "connais" la bibliothèque depuis peu mais peut
me rendre compte que pour quelqu'un la connaissant trés bien, elle peut
apporter je pense de la rapidité de programmation et d'éxécution,
Reste à voir si elle ne contient pas trop
de "quirks" pour me la rendre moins sympathique qu'une bibliothèque dédiée à
mon application mon généraliste mais plus lisible, déboguable (et peut être
plus efficace)
Mais je n'aurai une réponse qu'après une grande habitude et pratique de
cette bibliothèque qui comme le disait je ne sais plus qui a le gros
avantage de porter le nom "standard".
En fait, c'est utiliser autre chose que la STL qui demande justification.
.. ou developper des structures complexes de containers par la STL me semble
t-il...
Développer ses propres template demande plus de lecture et d'expérience.
Je manque d'expérience pour en parler. Mes propres classes template
m'ont beaucoup appris, mais ne sauraient passer en usage pour d'autres.
en tout cas merci pour ton point de vue qui me permet avec d'autres de me
faire une idée sur ce que je peux attendre de celle-ci.
En ce qui me concerne, la STL a été conçue par des gens plus expérimentés
que moi, puis testée par des dizaines de milliers de programmeurs, donc
elle a des avantages clairs.
L'avantage du standard, c'est que plus c'est utilisé, plus
l'investissement
est rentable.
Oui, la STL ne fait pas tout. Elle n'a pas d'arbre, pas de graphe.
J'ai eut à coder ce genre de choses, et je me suis pris les pieds
dans le tapis. Mais j'ai appris de mes erreurs, et je n'accuserai
pas la STL, plutôt ma volonté simpliste de me dire "je sais le
faire en C, ça me prendra pas plus de 2 jours de le faire en
C++/STL/template".
Après, j'ai codé des structures partagées, et en mettant les objets
contenus (en propriété) dans une liste, et des vecteurs d'itérateurs
sur la liste pour des sous-listes, ça c'est fait très vite.
En ce qui me concerne, la STL a été conçue par des gens plus expérimentés
que moi, puis testée par des dizaines de milliers de programmeurs, donc
elle a des avantages clairs.
L'avantage du standard, c'est que plus c'est utilisé, plus
l'investissement
est rentable.
Oui, la STL ne fait pas tout. Elle n'a pas d'arbre, pas de graphe.
J'ai eut à coder ce genre de choses, et je me suis pris les pieds
dans le tapis. Mais j'ai appris de mes erreurs, et je n'accuserai
pas la STL, plutôt ma volonté simpliste de me dire "je sais le
faire en C, ça me prendra pas plus de 2 jours de le faire en
C++/STL/template".
Après, j'ai codé des structures partagées, et en mettant les objets
contenus (en propriété) dans une liste, et des vecteurs d'itérateurs
sur la liste pour des sous-listes, ça c'est fait très vite.
En ce qui me concerne, la STL a été conçue par des gens plus expérimentés
que moi, puis testée par des dizaines de milliers de programmeurs, donc
elle a des avantages clairs.
L'avantage du standard, c'est que plus c'est utilisé, plus
l'investissement
est rentable.
Oui, la STL ne fait pas tout. Elle n'a pas d'arbre, pas de graphe.
J'ai eut à coder ce genre de choses, et je me suis pris les pieds
dans le tapis. Mais j'ai appris de mes erreurs, et je n'accuserai
pas la STL, plutôt ma volonté simpliste de me dire "je sais le
faire en C, ça me prendra pas plus de 2 jours de le faire en
C++/STL/template".
Après, j'ai codé des structures partagées, et en mettant les objets
contenus (en propriété) dans une liste, et des vecteurs d'itérateurs
sur la liste pour des sous-listes, ça c'est fait très vite.
"Marc Boyer" a écrit dans le message de
news: h7gl0i$47m$En ce qui me concerne, la STL a été conçue par des gens plus expérimentés
que moi, puis testée par des dizaines de milliers de programmeurs, donc
elle a des avantages clairs.
et oui ! et pourtant comment alors expliquer qu'il existent encore des bugs
dans certaines bibliothèques et même certains compilateurs de plus de 10 ans
d'ages (les bugs) ... ?!
L'avantage du standard, c'est que plus c'est utilisé, plus
l'investissement
est rentable.
oui, on a un minimum de garantie jusqu'à ce qu'on change de standard ;o)
Oui, la STL ne fait pas tout. Elle n'a pas d'arbre, pas de graphe.
J'ai eut à coder ce genre de choses, et je me suis pris les pieds
dans le tapis. Mais j'ai appris de mes erreurs, et je n'accuserai
pas la STL, plutôt ma volonté simpliste de me dire "je sais le
faire en C, ça me prendra pas plus de 2 jours de le faire en
C++/STL/template".
oui, tu touches là ce que je redoute ! ...
"Marc Boyer" <Marc.Boyer@cert.onera.fr.invalid> a écrit dans le message de
news: h7gl0i$47m$1@news.cict.fr...
En ce qui me concerne, la STL a été conçue par des gens plus expérimentés
que moi, puis testée par des dizaines de milliers de programmeurs, donc
elle a des avantages clairs.
et oui ! et pourtant comment alors expliquer qu'il existent encore des bugs
dans certaines bibliothèques et même certains compilateurs de plus de 10 ans
d'ages (les bugs) ... ?!
L'avantage du standard, c'est que plus c'est utilisé, plus
l'investissement
est rentable.
oui, on a un minimum de garantie jusqu'à ce qu'on change de standard ;o)
Oui, la STL ne fait pas tout. Elle n'a pas d'arbre, pas de graphe.
J'ai eut à coder ce genre de choses, et je me suis pris les pieds
dans le tapis. Mais j'ai appris de mes erreurs, et je n'accuserai
pas la STL, plutôt ma volonté simpliste de me dire "je sais le
faire en C, ça me prendra pas plus de 2 jours de le faire en
C++/STL/template".
oui, tu touches là ce que je redoute ! ...
"Marc Boyer" a écrit dans le message de
news: h7gl0i$47m$En ce qui me concerne, la STL a été conçue par des gens plus expérimentés
que moi, puis testée par des dizaines de milliers de programmeurs, donc
elle a des avantages clairs.
et oui ! et pourtant comment alors expliquer qu'il existent encore des bugs
dans certaines bibliothèques et même certains compilateurs de plus de 10 ans
d'ages (les bugs) ... ?!
L'avantage du standard, c'est que plus c'est utilisé, plus
l'investissement
est rentable.
oui, on a un minimum de garantie jusqu'à ce qu'on change de standard ;o)
Oui, la STL ne fait pas tout. Elle n'a pas d'arbre, pas de graphe.
J'ai eut à coder ce genre de choses, et je me suis pris les pieds
dans le tapis. Mais j'ai appris de mes erreurs, et je n'accuserai
pas la STL, plutôt ma volonté simpliste de me dire "je sais le
faire en C, ça me prendra pas plus de 2 jours de le faire en
C++/STL/template".
oui, tu touches là ce que je redoute ! ...
Le 28-08-2009, Christian PANEL a écrit :
> "Marc Boyer" a écrit dans le messa ge de
>news: h78bnm$lb__BEGIN_MASK_n#9g02mG7!__...__END_MASK_i?a63jfAD$ .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 !
Utiliser la STL et écrire ses propres templates ne sont
pas du tout le même problème.
Commençons par "utiliser la STL".
> deux versions de la STL ne sont pas obligées de fonctionner
> identiquement...
Heuh... Il peut toujours rester des bugs partout, mais en 2009,
la STL, elle me paraît bien stable et connue et implantée.
Le 28-08-2009, Christian PANEL <c.pa...@free.fr> a écrit :
> "Marc Boyer" <Marc.Bo...@cert.onera.fr.invalid> a écrit dans le messa ge de
>news: h78bnm$lb__BEGIN_MASK_n#9g02mG7!__...__END_MASK_i?a63jfAD$z__@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 !
Utiliser la STL et écrire ses propres templates ne sont
pas du tout le même problème.
Commençons par "utiliser la STL".
> deux versions de la STL ne sont pas obligées de fonctionner
> identiquement...
Heuh... Il peut toujours rester des bugs partout, mais en 2009,
la STL, elle me paraît bien stable et connue et implantée.
Le 28-08-2009, Christian PANEL a écrit :
> "Marc Boyer" a écrit dans le messa ge de
>news: h78bnm$lb__BEGIN_MASK_n#9g02mG7!__...__END_MASK_i?a63jfAD$ .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 !
Utiliser la STL et écrire ses propres templates ne sont
pas du tout le même problème.
Commençons par "utiliser la STL".
> deux versions de la STL ne sont pas obligées de fonctionner
> identiquement...
Heuh... Il peut toujours rester des bugs partout, mais en 2009,
la STL, elle me paraît bien stable et connue et implantée.