Documentation STL

John Deuf wrote on 16/03/2006 00:19:

Sylvain :

M$ supporte très mal la STL, sa doc dans le MSDN en est à l'image.

Tu plaisantes la ?
La STL de Microsoft est livree par Dinkumware, dont la qualite n'est plus
a demontrer.

on doit pas parler du même M$ ou pas du même environment, ma distrib.
contient essentiellement des fichiers "(c) 1994 by P.J. Plauger" dont la
lecture est ... ardue.

Concernant la doc STL de la MSDN, c'est la meilleure que je connaisse.

je n'ai pas dit que le MSDN est nul, ni le pire; il est exhaustif et
énumératif, il lui manque peut être d'être synthétique et descriptif
(une approche à la howto qui permets d'intuiter au dela des devinettes
sur les noms).

j'ai dit par contre que je considérais que la STL est (globalement) mal
supportée, cela dépasse la simple doc du MSDN: les samples de l'édition
Oct2005 ne contiennent qu'un seul usage de std::map, 1 de std::advance,
4 de std::vector et 4 de std::list; cela fait peu; par ailleurs je vois
M$ bcp plus communiquer sur son C# que participer à l'évolution de la
norme STL.

Et comment presentes-t-on les arguments par defaut ou les fonctions
surchargees (a part en recopiant le code source) ?

je n'ai rien contre la recopie de code, elle peut s'accompagner d'un
résumé littéraire du but à atteindre et de l'avantage de la méthode
apporté par telle classe de la STL; bien que l'info soit bcp plus dilué
dans le C++ Prog. Lang. de Bjarne Str. je préfère sa présentation qui
donne à comprendre de l'intérêt de chaque classe.

Sylvain.

Sylvain wrote on 16/03/2006 01:46:

Tu plaisantes la ?
La STL de Microsoft est livree par Dinkumware, dont la qualite n'est
plus a demontrer.

on doit pas parler du même M$ ou pas du même environment, ma distrib.
contient essentiellement des fichiers "(c) 1994 by P.J. Plauger" dont la
lecture est ... ardue.

ok, raté, Dinkumware est précisemment l'éditeur de Plauger.
m'apprendra à pas googoliser à temps.

Sylvain.

Sylvain wrote:

John Deuf wrote on 16/03/2006 00:19:

Sylvain :

M$ supporte très mal la STL, sa doc dans le MSDN en est à l'image.

Tu plaisantes la ?
La STL de Microsoft est livree par Dinkumware, dont la
qualite n'est plus a demontrer.

on doit pas parler du même M$ ou pas du même environment, ma
distrib. contient essentiellement des fichiers "(c) 1994 by
P.J. Plauger" dont la lecture est ... ardue.

Et tu as quelle distribution? Dans <string>, j'ai "(c)
1992-2005 by P.J. Plauger". Et c'est sans discussion possible
une des meilleurs implémentations que je connais -- nettement
mieux que RogueWave ou STLport, et un peu mieux que celle de
g++.

Ça a prèsque toujours était le cas. Quand VC++ 6.0 est sorti,
par exemple, g++ n'avait même pas encore les nouveaux streams.

On peut ne pas être d'accord sur la politique commerciale de
Microsoft, mais il faut avouer que sur le plan technique, ils
ont actuellement un des meilleurs compilateurs disponibles.
(C'était toujours le cas en ce qui concerne la bibliothèque. Ce
n'était pas du tout le cas avant en ce qui concernait le
compilateur proprement dit.)

--
James Kanze GABI Software
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

kanze wrote on 16/03/2006 09:36:

on doit pas parler du même M$ ou pas du même environment, ma
distrib. contient essentiellement des fichiers "(c) 1994 by
P.J. Plauger" dont la lecture est ... ardue.

Et tu as quelle distribution?

un truc communément appelé "everything but flight simulator".

Dans <string>, j'ai "(c) 1992-2005 by P.J. Plauger".

oh ben (presque) pareil alors !!

il s'agissait de la distrib. pour VC6, je ne te renvoie pas la question
mais tu as oublié d'indiquer que la distrib. "(c) 1992-2005" est celle
de vc2005.

Et c'est sans discussion possible une des meilleurs
implémentations que je connais -- nettement mieux
que RogueWave ou STLport, et un peu mieux que celle de g++.

dont acte, meilleure implémentation, pire à lire.

On peut ne pas être d'accord sur la politique commerciale de
Microsoft, mais il faut avouer que sur le plan technique, ils
ont actuellement un des meilleurs compilateurs disponibles.

je n'ai pas parlé non plus de commercial pur; j'imagine que tu as lu les
discussions *techniques* entre adorateurs des nouvelles technos vs
gardiens de la compatibilité ascendante.

(C'était toujours le cas en ce qui concerne la bibliothèque.
Ce n'était pas du tout le cas avant en ce qui concernait le
compilateur proprement dit.)

s'il faut vraiment lire "c'était tjrs le cas" (je m'attendais à "ce
n'était pas tjrs le cas"), il faut sûrement penser que les créateurs de
WTL (rien qu'un exemple) n'ont rien compris à MFC (et je passe sous
silence ceux n'ayant rien compris à ATL).

Sylvain.

Sylvain wrote:

kanze wrote on 16/03/2006 09:36:

on doit pas parler du même M$ ou pas du même environment,
ma distrib. contient essentiellement des fichiers "(c) 1994
by P.J. Plauger" dont la lecture est ... ardue.

Et tu as quelle distribution?

un truc communément appelé "everything but flight simulator".

Ce qui ne me dit rien. (N'oublie pas que je n'ai pas trop
l'habitude du monde Windows.)

Dans <string>, j'ai "(c) 1992-2005 by P.J. Plauger".

oh ben (presque) pareil alors !!

il s'agissait de la distrib. pour VC6, je ne te renvoie pas la
question mais tu as oublié d'indiquer que la distrib. "(c)
1992-2005" est celle de vc2005.

Tout à fait. En fait : « Visual Studio 2005 Express Edition ».
La version gratuite, quoi -- puisque je ne m'en sers pas au
développement, on ne me le paie pas (et je n'ai pas de machine
Windows à la maison sur laquelle je pourrais installer une
version achetée).

Et c'est sans discussion possible une des meilleurs
implémentations que je connais -- nettement mieux que
RogueWave ou STLport, et un peu mieux que celle de g++.

dont acte, meilleure implémentation, pire à lire.

Je ne suis pas sûr ce que tu essaies à lire. Par sa nature même,
et les contraints que lui impose la norme, une *implémentation*
de la bibliothèque standard serait difficile à lire. Je ne
venture dans les sources g++ que quand je me doute d'une erreur.

En ce qui concerne la doc, j'ai toujours trouvé les pages de
Dinkumware assez lisable. Quant à la documentation Microsoft, je
ne peux rien dire en ce qui concerne la bibliothèque -- je l'ai
trouvé positivement superbe pour mes besoins, ce qui se sont
limités (sur Windows) à porter des programmes existants
développés sous Unix, avec des fichiers GNU make et de la
génération automatique du code à certains endroits au moyen des
outiles Unix. C-à-d que sous Windows, je compile avec ligne de
commande sous CygWin. Et j'étais positivement étonné que
Microsoft en fournissait toute la documentation nécessaire pour
le faire, sans problèmes, étant donné que ce n'est sûrement pas
comme ça qu'ils envisage le développement « normal ». Dans
l'ensemble, je suis positivement ébloui par la qualité et de la
documentation et du compilateur même.

Pour la documentation de la bibliothèque standard, je me
retourne systèmatiquement à la copie de la norme C++98 que j'ai
sur ma système. Mais je crois que je suis un peu spécial à cet
égard -- et je ne prétendrais pas que la norme est ce qu'il y a
de plus lisible, même comme réference pûre. (Elle n'a évidemment
pas de but pédagogique.)

On peut ne pas être d'accord sur la politique commerciale de
Microsoft, mais il faut avouer que sur le plan technique,
ils ont actuellement un des meilleurs compilateurs
disponibles.

je n'ai pas parlé non plus de commercial pur; j'imagine que tu
as lu les discussions *techniques* entre adorateurs des
nouvelles technos vs gardiens de la compatibilité ascendante.

J'en ai même participé. En tant que responsable des milliers de
lignes du code existant, c'est évident de quel côté je me
penche.

En fait, mon commentaire ne te visait pas directement. Il y a un
nombre important des gens qui laissent leurs opinions techniques
colorer par leurs opinions sur la politique commerciale de
Microsoft.

(C'était toujours le cas en ce qui concerne la bibliothèque.
Ce n'était pas du tout le cas avant en ce qui concernait le
compilateur proprement dit.)

s'il faut vraiment lire "c'était tjrs le cas" (je m'attendais
à "ce n'était pas tjrs le cas"), il faut sûrement penser que
les créateurs de WTL (rien qu'un exemple) n'ont rien compris à
MFC (et je passe sous silence ceux n'ayant rien compris à
ATL).

Je ne sais pas ce que WTL ou ATL signifient. En revanche, quand
je parlais de la qualité de la bibliothèque, je parlais de la
bibliothèque standard -- le peu que j'ai vu de MFC ne m'a pas
emballé du tout. Mais l'implémentation de la bibliothèque
standard dans VC 5 ou dans VC 6 était nettement en avance de
celle de Sun CC ou de g++ de la même époque -- voire même de
celle de Sun CC aujourd'hui.

Sylvain wrote:

adebaene@club-internet.fr wrote on 15/03/2006 13:11:

Plait-il ?????

c'est un forum, pas un chat il me semble.

Alors je refomule... Qu'est ce qui te fais dire que MS supporte très mal la
STL au juste?

Arnaud

Arnaud Debaene wrote on 19/03/2006 11:22:

Sylvain wrote:

adebaene@club-internet.fr wrote on 15/03/2006 13:11:

Plait-il ?????

c'est un forum, pas un chat il me semble.

Alors je refomule... Qu'est ce qui te fais dire que MS supporte très mal la
STL au juste?

comme je l'ai indiqué en réponse à James:
- le fait que la description de la STL dans la référence librairie du
MSDN soit minimaliste (uniquement exhaustive et énumérative et non
descriptive), il y a par exemple 34 pages d'overview pour ATL et 4 pages
pour la partie STL Overview,
- le fait qu'il n'y ait quasi exemple exemple de code utilisant la STL
(soit qlq samples sont présents dans les pages propres à certaines
méthodes ou opérateurs).

accessoirement le fait que Microsoft ne m'ait jamais convié à une
présentation de "son" implémentation et "ses" outils basés sur la STL
(contre des dizaines de messes pour C#).

"supporter" signifiait donc techniquement ("support technique") et
commercialement (garanti de pérennité) et non seulement inclure une
implémentation dans sa distribution (que j'aurais tendance à considérer
obligatoire pour un produit se présentant comme un outil de dev. C++).

Sylvain.

Sylvain wrote:

Arnaud Debaene wrote on 19/03/2006 11:22:

Sylvain wrote:

adebaene@club-internet.fr wrote on 15/03/2006 13:11:

Plait-il ?????

c'est un forum, pas un chat il me semble.

Alors je refomule... Qu'est ce qui te fais dire que MS supporte très
mal la STL au juste?

comme je l'ai indiqué en réponse à James:
- le fait que la description de la STL dans la référence librairie du
MSDN soit minimaliste (uniquement exhaustive et énumérative et non
descriptive), il y a par exemple 34 pages d'overview pour ATL et 4
pages pour la partie STL Overview,
- le fait qu'il n'y ait quasi exemple exemple de code utilisant la STL
(soit qlq samples sont présents dans les pages propres à certaines
méthodes ou opérateurs).

Ok, je reprends le raisonnement :
Toi : "M$ supporte très mal la STL, sa doc dans le MSDN en est à l'image."
Moi : "Qu'est ce qui te fais dire que MS supporte très mal la STL au juste?"
Toi :<Paraphrasé> : La doc est à ù*$^ù, ca prouve, qu'ils supportent mal la
STL

Comme raisonnement circulaire, ca se pose là!

accessoirement le fait que Microsoft ne m'ait jamais convié à une
présentation de "son" implémentation et "ses" outils basés sur la STL
Pour info, ce n'est pas MS qui a écrit "son" implémentation de la STL, c'est

Dinkumware.

(contre des dizaines de messes pour C#).
L'art de comparer l'incomparable : Un langage contre une librairie....

"supporter" signifiait donc techniquement ("support technique")
et commercialement (garanti de pérennité) et non seulement inclure une
implémentation dans sa distribution (que j'aurais tendance à
considérer obligatoire pour un produit se présentant comme un outil
de dev. C++).

Les conditions de support de la STL sont exactement les mêmes que le support
du reste du produit... Par ailleurs, si tu connais un vendeur qui fais mieux
(ou moins pire si tu préfères) sur le sujet, je suis preneur.

PS : Il y a effectivement à mon avis un problème de support de la STL, comme
le prouve ce fil de discussion, mais c'est un problème général à tous le
produits AMHA.

Arnaud

Arnaud Debaene wrote on 19/03/2006 22:53:

Ok, je reprends le raisonnement :

non tu veux définir un raisonnement qui n'a jamais été mon propos.

Toi : "M$ supporte très mal la STL, sa doc dans le MSDN en est à l'image."

"être à l'image de" signifie (généralement) avoir la même qualité, ou
les mêmes défauts; donc si le français t'échappe:

M$ ne fait pas bcp d'effort pour évangéliser, favoriser, utiliser,
valoriser la STL, et par conséquent la doc du MSDN ne fait pas non plus
bcp d'effort pour .....

Moi : "Qu'est ce qui te fais dire que MS supporte très mal la STL au juste?"
Toi :<Paraphrasé> : La doc est à ù*$^ù, ca prouve, qu'ils supportent mal la
STL

Comme raisonnement circulaire, ca se pose là!

comme détournement ou méprise aussi.

accessoirement le fait que Microsoft ne m'ait jamais convié à une
présentation de "son" implémentation et "ses" outils basés sur la STL
Pour info, ce n'est pas MS qui a écrit "son" implémentation de la STL, c'est

Dinkumware.

déjà dit 4 fois dans ce fil.

(contre des dizaines de messes pour C#).
L'art de comparer l'incomparable : Un langage contre une librairie....

tu fais exprès là ?!?? ou tu n'as pas compris que C# généralisé fera
justement disparaitre ces libraries (ie la STL, un CRT +/- standard, ...)

Les conditions de support de la STL sont exactement les mêmes que le support
du reste du produit...

alors tout va bien.

Par ailleurs, si tu connais un vendeur qui fais mieux
(ou moins pire si tu préfères) sur le sujet, je suis preneur.

si la question est qu'est ce qu'il pourrait être fait pour faciliter,
répandre, généraliser l'usage de la STL, je constate que des personnes
(jamais des "vendeurs", rarement des éditeurs logiciels) y contribuent.

Sylvain.

Sylvain wrote:

Arnaud Debaene wrote on 19/03/2006 22:53:

Pour revenir à un niveau plus général, parce qu'il y a une chose
que je n'ai pas bien compris dans la discussion...

Qu'est-ce que ça veut dire, « supporter » au juste, ici ? Parce
que la STL fait partie du langage C++ ; ce n'est pas une
bibliothèque propre à Microsoft, ni à aucun autre fournisseur du
C++. Et je me pose la quesion : jusqu'à quel niveau est-ce qu'il
revient au fournisseur de documenter le langage ? Les
documentations de mes compilateurs C++, par exemple, n'explique
pas que les violations de la ODR, ou la modification d'une même
variable plus d'une fois sans un point de séquencement
entretemps, mènent à un comportement indéfini. Ces règles font
partie du langage, et ils (les fournisseurs, c-à-d Sun et GNU,
en ce qui me concerne) partent du principe que c'est à
l'utilisateur de l'apprendre. Ça vaut pour les langages
« repandus », comme C et C++, mais pas pour d'autres choses --
GNU make, ou bison, ont une documentation assez complète, à la
fois tutorielle et de référence.

Et c'est une vraie question, dont je ne sais pas réelement la
réponse -- sur ma machine (Solaris 2.8), sed est documenté en
détail, mais la documentation de awk ne suffira pas pour écrire
grand chose. Pourquoi l'un, et pas l'autre ? (Peut-être le fait
que Kernighan a écrit un livre sur AWK ?) Mais parler de la
qualité de la documentation de la STL n'a de sens que si on y a
répondu. La STL fait partie du C++, et je m'attends à ce qu'un
programmeur C++ le connaisse, dans le même sens que je m'attends
à ce qu'il connaisse comment fonction le surcharge des
fonctions. Jusqu'à quel point est-ce que la documentation sur ce
genre de choses doit se trouver dans la documentation du
compilateur ?

--
James Kanze GABI Software
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