lmg HS a écrit 174 commentaires

Je partage cette analyse (mais ne je peux faire de up avec la politique d'attribution de points du site : on finit par les perdre quand on commente peu)

Certes avec docbook, on peut décorer le document avec des infos supplémentaires plus proprement qu'avec LaTeX -- comme rajouter un signe à teneur sémantique à chaque titre.

Mais je trouve que les projets satellites ne sont pas aussi aboutis:

- la chaine qui passe par fop produit un résultat bien plus pauvre que pdfLaTeX

- les styles docbook-xsl ne sont pas encore très matures. J'avais dû aller bidouiller de longues sections du style qui n'étaient pas du tout /Open-Close/ pour pouvoir paramétrer divers éléments.

- je n'ai pas trouvé d'éditeur docbook aussi agréable qu'un éditeur de texte (vim pour moi, emacs pour d'autres, ...), et le formatage XML alourdit trop le texte pour une édition agréable dans les éditeurs usuels.

Quand on a besoin de décoration, j'ai l'impression que l'idéal est probablement le mélange docbook -> LaTeX -> pdf. Sinon, LaTeX, c'est bien quand même.

Le but n'est pas d'augmenter la quantité de template, mais d'augmenter la quantité de RAII pour réduire, entre autres, la quantité de pointeurs (bruts).

Qu'entends tu par contenu ?

Le contenu de ton fichier ? Oui, c'est normal de ne pas le voir sur un print dans gdb. De même qu'en C un FILE* ne permet pas de voir ce qu'il y a sur le disque.

Au mieux, tu pourras espionner le contenu du streambuf s'il fonctionne comme un cache.

Je soupçonne très fortement que ton erreur est ailleurs.

a- Est ce que crée des classes les détruire et appeler des fonctions membre de classe est plus lent qu'appeler des fonctions ?
c--Est ce que en réglant une fuite de mémoire j'ai rajouter des delete qui prennent beaucoup de temps ?
d-Est ce que c'est pas normal et que je devrais repenser la façon dont j'ai écris le code ?
a- Seulement si:
- tes objets ne vivent pas sur la pile, auquel cas tu peux payer une allocation dynamique que tu n'avais pas sinon
- tu t'es amusé à rajouter des virtual sans raison -- i.e. si tu n'avais pas de vrai point de variation à l'endroit des appels de fonctions virtuelles.

c- Si tu fais delete + new derrière en boucle ... tu pourrais consommer plus de temps que nécessaire.
P.ex., pour des tableaux, il peut être plus efficace de bosser avec un vecteur et de provoquer des resize(), plutôt que de reconstruire à chaque boucle.

d- Pour float vs double, je ne m'avancerai pas ; pour les options de compilation, j'imagine que tu utilises les mêmes partout ; l'utilisation des streams peut ralentir ; donc pour une simple conversion, il ne devrait pas y avoir d'impact.

A tout hasard, cf le TR on C++ performances (n18015) sur le site du comité de standardisation.

VC6 qui date accessoirement de 97, pour une norme qui date, elle, de 98. Pour un compilo qui pré date la norme, il s'en sort pas trop mal.

Si seulement il ne s'était pas imposé comme un standard persistant en industrie... :(

> Je me demande s'ils n'ont pas également abandonné certains compilos encore plus vieux et exotiques que certains pas vraiment réputés pour leur niveau de conformité.

> Clairement l'approche à l'opposé de celle de boost.

Oups, j'ai foiré la transition ^^'
Je voulais dire: dans ce cas: ils ont dû enfin abandonné certains vieux compilos ; alors leur volonté me parait d'être de supporter tous les compilos encore utilisés en industrie (donc VC6 p.ex)
A l'opposé boost néglige les anciennes versions des compilos.

> Un certain nombre de ces critiques ont disparu aujourd'hui, en grande partie à mon avis parce que Trolltech a fait des efforts pour rapprocher Qt de la STL.

Je me demande s'ils n'ont pas également abandonné certains compilos encore plus vieux et exotiques que certains pas vraiment réputés pour leur niveau de conformité.
Clairement l'approche à l'opposé de celle de boost.

> C'est d'ailleurs un autre reproche qu'on peut faire à la std::lib : sans la lib c, elle ne sert pratiquement à rien

Ben ... pourquoi tout réinventer ?
Accessoirement, je n'avais pas relevé précédemment, mais il y a une version C++ de tolower qui prend une locale en paramètre (le C++ a une approche que je trouve assez bizarre vis à vis de l'I18n). De fait, il est est faux de dire qu'il _faut_ repartir sur le C (dans ce cas! Dans d'autres, je ne dis pas).


> C'est marrant, quand on critique la STL, les gens ressortent toujours l'exemple du sort. On peut en effet trier n'importe quel container avec la STL, et on peut aussi choisir son algo de tri très facilement.

C'est un exemple de la séparation organisation/algorithme sauce STL. Je me sers tout autant des copy_if (OK, c'est un oubli du standard), remove_xxx, equal_range, etc.
De nouveau, le PDF de Stepanov est des plus intéressants.

Tout à fait. C'est de nouveau un sous dialecte ; avec les problèmes de portabilité de développeurs que j'évoquais précédemment.

Au détail que boost a légèrement noyauté le prochain standard et que l'ensemble de ses définitions complètent généralement la SL plutôt que de chercher à s'y substituer.

Et le jour où ton employeur t'affecte à un projet C++/MFC ou C++/gtkmm ?

Mon point n'était pas lié à la simplicité apportée (cf ma seconde phrase deux messages plus hauts) , mais à la non portabilité des développeurs introduites par ces dialectes propriétaires. Soit une vaine (?) tentative de décrypter ce qui est entendu par "pur".

La practicité du foreach de Qt est un fait. Il y a des gens qui se sont amusés à inventer le même genre de trucs avec boost. Leur pérennité est juste faible vu qu'il va y avoir autre chose pour remplacer: http://en.wikipedia.org/wiki/C%2B%2B0x#Range-Based_For_Loop

C'est le problème des extension propriétaires. Si elle les restent, le standard fini par gagner -- quand il y a redondance.

hum ... std::for_each() ?

Cette "pureté" (je n'aime pas le terme non plus), c'est ce qui apporte la portabilité du développeur.

A avoir des macros, même simplificatrices, qui s'utilisent en place des artifices officiellement fournis par le langage, on s'engage dans un sous-dialecte qui n'aide pas à la migration des développeurs.

C'est comme cela que l'on se retrouve à avoir du C++/MOC, du C++/MFC, etc
Résultat, on se retrouve avec des gens qui doivent ouvrir une nouvelle doc (propriétaire! (à un framework)) pour utiliser des structures qui sont pourtant fournies en standard, lorsqu'ils migrent sur des projets qui reposent sur d'autres frameworks (wxWidgets, Qt, MFC, ACE, ...)

Attention, il est normal de s'adapter aux widgets du framework. Ce que je considère de complètement anormal est de s'adapter relativement aux choses dont un équivalent est pourtant fourni en standard (je pense aux itérateurs aliens (dans le contexte C++) de Qt, à leur FOREACH, etc, et de même pour les autres frameworks qui empiètent sur la SL, ou qui poussent à l'utilisation de macros dans le code client)


Après, et cela n'engage que moi, je ne crois pas en la pérennité des sous-dialectes -- même si certains font de la résistance (-> MFC). Si TT/Nokia poussait certains des éléments de Qt dans le prochain standard, ma foi cela pourrait assurer une pérennité. Mais, AFAIK, ce n'est pas le cas. Ils m'ont l'air de rester gentiment dans leur coin avec leurs clients. A côté de ça Adobe, dont ce n'est pourtant pas le métier de fournir un framework de fenétrage, publie des articles "théoriques", et s'investit dans les communautés motrices relativement à l'avenir du C++ (au travers de 3-4 individus).

> de mélange entre fonctions C (tolower)

Ou de savoir chercher dans une FAQ ...
Mais même là, la réponse n'est pas simple suite à divers choix relatifs à l'interface de std::string, et aux locales.
Sinon, boost c'est pas mal aussi...

Mais c'est sûr, qu'à faire du C++ sans connaitre la SL (-> itérateurs et autres algorithmes), on passe à côté de pas mal de choses et on se complique bien la vie. L'absence de vrais supports pour enseigner ce C++ (plutôt que du C avec des classes) n'aide pas.


[sinon, j'ai globalement la même perception qu'Etienne -- pour la petite histoire, Stroustrup utilise Qt dans son enseignement du langage]

4. Ne pas oublier les simples valeurs.

Je n'ai jamais dit que le langage était simple.

Quant à la complétion automatique, les polymorphismes moins dynamiques (macrotage hérité du C, template, ...) n'aident effectivement pas. Dans leurs blogs, des gens de l'équipe de VS parlent qu'ils sont en train de remettre les choses à plat. Il faudra voir ce que cela pourra bien donner. Je serais curieux aussi de tester (dans 2 ans ...) cet autre outil dont on nous a fait de la pub ces dernières semaines (histoire de remplacer ctags qui ne comprend vraiment pas grand chose au C++)

> Qt utilise massivement le copy on write

Le COW n'est pas un gage de qualité pour tout le monde. Le seul intérêt que je lui vois, c'est de palier à l'absence de sémantique de déplacement dans la version courante du C++ (le C++0x introduira les rvalue references qui changeront la donne -- compter 15 ans avant que Qt en profite (volonté de supporter toutes les plateformes, même celles qui ne sont plus supportées par les fournisseurs de compilos)). Et juste pour cela : faire des retours de fonctions par valeur, on sort une usine à gaz, à savoir le COW.


> sort est une methode, pas une fonction externe

Et oui, sort s'applique aussi sur les tableaux, pas que sur les vecteurs ou les files. Pourquoi dupliquer le code ?

Une école tend à considérer que les fonctions ne doivent être membre qu'en dernier recourt -- je simplifie.
Visiblement, Stepanov aurait mis bien moins de choses en membre comme begin()/end() s'il avait pu faire ce qu'il voulait.
Cf ses notes sur la programmation: http://www.stepanovpapers.com/notes.pdf

> std::string

souffre en effet d'un certain nombre de défauts.

J'avais vu /The last man on earth/ il y a un an ou deux, et j'avais trouvé qu'il correspondait plutôt bien à mes souvenirs du livre (lu 10 ans plus tôt).

NB: ce n'est pas du tout un film d'action, ni d'effets spéciaux.

Après je ne peux pas comparer avec /I am legend/ que je n'ai pas encore vu.

Il y a boost.format qui propose un service semblable, mais de façon assez différente. AMHA, boost.format est beaucoup plus sûr vu qu'il ne repose pas sur la la notion de fonction variadique (-> '...'), et plus puissant aussi.

Pas oublier aussi toutes les fois où une CString était directement passée à un "const char*", avec les chaînes standard, il faudra faire des appels explicites à std::string::c_str().

Il devrait aussi y avoir des différences par rapport à l'aspect UNICODE & cie, si je me souviens bien.

Autrement, j'avais croisé sur codeguru/codeproject (?) des classes mimant le comportement (et le nom) de CString.
A termes, j'ai envie de dire que mieux vaut migrer vers la chaine standard.

[pinaillage]
PS: std::string ne fait pas parti de la STL historique. Juste de la SL du C++
[/]

C'est toute la différence, quand je manipule des entités (comme ici avec une hiérarchie polymorphe), j'ai les copies en horreur. Rien de tel pour perdre l'entité à chaque fois que son état doit évoluer -- sans parler de la complexité pour avoir une semantique de copie fiable sur des entités (polymorphes, c'est pire) en C++. Les valeurs, naitre et mourrir sans cesse est dans leur essence, les entités persistent et se lient.

L'entité initiale, on ne s'en tamponne pas, c'est ce qui permet d'établir des liens entre les diverses entités du système (proprio, préfecture, voiture, auto radio, carte grise, moteur, roues, ...). À chaque mutation de type, c'est tous les liens que l'on doit retisser.

Accessoirement, avec le state pattern on ne requalifie pas entièrement une entité, mais l'état d'une entité.

Des champs spécifiques à la voiture achetée ....? Hum, la carte grise, le contrat d'entretien, la garantie, les références du vendeur, ... Chacune des classes peut être amenée à fournir cela à une tierce partie.

Ou si tu préfères, tu prends une voiture et ses passagers. Un passager observe le monde voiture (chercherAutoradio) et agit eventuellement dessus (ouvrirPorte), la voiture va envoyer des feedbacks vers ses passagers (crash, ...).
Tu ne va quand même pas avoir 2^4 classes de voitures pour chacun des passagers qui peut être ou ne pas être là tout de même ?

Euh... je veux pas dire, mais là c'est bien pire.

* Comment tu va réaliser la migration du type effectif de Voiture vers VoitureAchetee ? En recopiant chacun des champs ? Non ! Une voiture est une entité, en effectuant des copies, tu brises toutes les références à l'entité initiale.

* Et comment obtenir une VoitureAchetee à partir d'un PriopriétaireVoiture ? En downcastant ? (si ça c'est pas un rejeton du démon.. :-/)

Les liens bi-directionnels (0..*) existent, et ils ne sont pas le mal incarné. Il faut même leur reconnaitre un avantage : ils poussent à utiliser des déclarations anticipées ce qui améliore les temps de (re)compilation.

Bon, avec un problème entièrement formulé, on pourrait proposer une modélisation correcte. Là, en partant sur des généralités, on va parler dans le vide.

+1 à "déjà répondu" ... d'autant que pour une fois (que tu es chanceux!), j'ai donné le lien précis dans la FAQ de developpez.

Par contre, les références circulaires ne me gêne pas plus que cela. J'ai vu des abus sur quantité de pièges à débutants en OO, mais ça, pas encore.

Il n'a pas un problème d'inclusions multiples (au sein d'une même unité de traduction), mais de dépendances circulaires.
Le fait qu'il y ait des inclusions est anecdotique ici.

La réponse dans la FAQ de developpez:
http://c.developpez.com/faq/cpp/?page=classes#CLASS_referenc(...)

Oups. J'avais zappé la réponse de Zénitram. Désolé pour le doublon.

http://c.developpez.com/faq/cpp/?page=strings#STRINGS_affect(...) (suivre le lien) =>

std::ostringstream oss;
oss << "toto" << 42;
const std::string chaine = oss.str();

Tu as des scripts comme EnhancedCommentify qui savent décommenter et décommenter des zones de texte dans une pléthore de langages. Accessoirement, c'est facilement extensible.

Le script se trouve rapidement sur http://vim.sf.net

Il fait parti des scripts que j'utilise le plus.

L'idée est précisément de voir les langages dans l'ordre de leur apparition car chaque génération s'appuie sur la précédente et les modifications apportées servent justement à lever ses limitations

Et pourquoi on ne voit pas le B avant alors ? Et quantité d'autres choses d'ailleurs ? http://lambda-the-ultimate.org/node/7

Passer au C comme premier langage compilé peut rebuter plus d'une personne.

Le langage C n'est pas « un mauvais moment qu'il faudra passer »

Je n'ai pas dit ça (ni ici, ni dans les liens que j'avais donnés!). J'ai dit que des aspects primordiaux du C se tapaient l'inscruste trop tôt dans l'apprentissage et le parasitaient. L'apprentissage (non historique) du C++ permet de voir ces aspects une fois que les bases sont consolidées.

Nul besoin de montrer trop de choses d'un coup, dont des mauvaises habitudes qu'il est toujours dur de perdre.

NB: je n'ai jamais dit qu'il fallait commencer par l'OO. Je n'ai jamais dit qu'il ne faut pas voir les pointeurs. Je dit juste qu'il faut voir les choses dans l'ordre qui permet leur meilleure assimilation.

Je renvois au passage à l'article de Stroustrup dans sa FAQ (sur le pourquoi le C++ doit être enseigné comme un langage à part entière). A méditer.

Bouaif pour la v1.xx du cours de Christian Casteyde -- je n'ai jamais lu la v2

Sinon, je fais parti de ceux qui considère que le C est trop bas niveau dans un premier temps. Le C++ permet de mettre l'accent sur des notions plus importantes que les formats de printf et les pointeurs au second chapitre. Le tout est de retarder ces choses du C jusqu'au moment opportun.

(je conseille le C++ avant le C pour les mêmes raisons que je conseillerai d'autres langages comme le Pascal ou l'Ada avant)

Sujet débatu et archi-débatu
http://developpez.net/forums/showthread.php?t=327
http://developpez.net/forums/showthread.php?t=1489
(entre autres)