Discussion :

[Mac LAK]

Désolé Mac LAK d'éditer ton message.

Je viens de séparer la conversation faite dans le thread du 4eme défi pour mettre dans cette discussion tout ce qui ne concerne pas le défi.

Hihi^^
Bon je suis pas là pour faire l'apologie de la STL à quelqu'un qui sait certainement trés bien s'en passer. Sache seulement que j'ai commencé le C a 14 ans, et le C++ a 20, et que je suis pas du genre a codé qu'une fois de temps en temps.
Je suis d'accord qu'il FAUT savoir faire autrement et que la STL a ses limites. D'ailleur je serais tout a fait capable de (re)faire sans. Mais dans mon cas personel la STL/boost répondent a 99.9% a mais problème de structure de données, donc j'en use et j'en abuse avec joie. Et c'est surement de m'être galeré aussi longtemps en C qui me fait apprécier autant la STL. (Je précise que j'ai rien contre le C)

Sûr que pour des "petites" structures, sans contraintes particulières de performances lourdes, ou de consommation mémoire, la STL ou Boost répondent aux besoins. C'est souvent le cas dans pas mal de projets graphiques par exemple, où l'affichage est le plus gros consommateur de temps CPU, ou des programmes de communication pour lesquels le temps de propagation des trames est souvent bien supérieur au temps de traitement.

Mais là où je suis plus gêné, justement, c'est de "faire apprendre" à des débutants exclusivement via la STL / Boost sans leur en montrer les limites... Là, je parle par expérience, j'ai vu trop de débutants utiliser des trucs dix fois trop lourds dans des parties de code critique, ou pire, ne pas savoir utiliser des éléments "basiques" comme un simple "TYPE*" en guise de tableau, ne pas savoir faire un sizeof correct, etc.

Pour moi, un exemple de "mauvaise réponse" à un problème, c'est de dire d'utiliser telle fonction de telle librairie quand, manifestement, le posteur cherchait à comprendre comment le faire... Il est humain, et ira sûrement vers la facilité d'utiliser un truc tout prêt, mais du coup aura perdu le fait d'apprendre à le faire par lui-même.

Faut pas réinventer la roue à chaque programme, bien sûr, mais il faut savoir le faire au besoin.

[maxim_um]

Salut tout le monde,

Sûr que pour des "petites" structures, sans contraintes particulières de performances lourdes, ou de consommation mémoire, la STL ou Boost répondent aux besoins...

Tu t'avances dans un terrain miné, là!!!

La SL est une pierre angulaire du langage, Boost se confirme et le devient. Et c'est justement dans les aspects critiques qu'ils montrent toutes leurs puissances. Ils ne peuvent être reniés de la sorte. C'est comme tout, si tu donnes une Ferrari à quelqu'un qui ne sait pas conduire, s'il se plante, c’est pas la faute à la voiture. Et pourtant, tu conviendras qu'il avait un sacré bolide entre les mains. Eh ben, pour la SL et Boost, c'est pareil.

[Mac LAK]

Tu t'avances dans un terrain miné, là!!!

La SL est une pierre angulaire du langage, Boost se confirme et le devient. Et c'est justement dans les aspects critiques qu'ils montrent toutes leurs puissances. Ils ne peuvent être reniés de la sorte. C'est comme tout, si tu donnes une Ferrari à quelqu'un qui ne sait pas conduire, s'il se plante, c’est pas la faute à la voiture. Et pourtant, tu conviendras qu'il avait un sacré bolide entre les mains. Eh ben, pour la SL et Boost, c'est pareil.

Pas vraiment, hélas, et par expérience... Je dirais même que filer la STL comme "référence" à un débutant lui interdit souvent de comprendre comment elle fonctionne réellement en interne, ou ce que cela retire comme charge de développement. Comme je l'ai précisé un peu plus haut, je trouve "dangereux" (et j'en ai des preuves constamment hélas) de laisser des débutants croire que la STL est la panacée intégrale sans leur apprendre à le faire "à la main"... Déjà, parce que quand tu es tenu de compiler en C pour des raisons de contraintes de plate-forme (et non pas en C++), ça pleure. Ensuite, parce que même en C++, la STL n'est pas toujours une bonne idée.

La STL (et les templates de façon générale d'ailleurs) sont infects à débugger, ont une fâcheuse tendance à augmenter significativement la taille du code binaire produit (souvent gênant en embarqué), et cèdent systématiquement devant le code "manuel" lorsque l'on gère d'énormes quantités de données fréquemment modifiées (ex : buffers de communication), ou que l'on a besoin de vitesses d'exécutions particulièrement contraintes (gestionnaires temps réel par exemple)...

Note bien que quand je parle de "énormes quantités de données", je parle de centaines de milliers d'entrées pesant chacune plusieurs kilo-octets, pour une taille totale flirtant avec le gigaoctet, et ayant en moyenne une durée de vie de quelques millisecondes... Quand en plus tu mets là-dessus un système de priorités, je te promets qu'utiliser la STL va plus te plomber qu'autre chose, ne serait-ce que parce qu'elle ne saura JAMAIS créer les "bons" index d'elle-même.
Et si c'est pour finir par transformer des std::map en collections de std::vector de tailles statiques, autant utiliser un bon mieux "new", tu ne crois pas ?

Après, sur des données de type configuration, peu lues / modifiées et en dehors du chemin critique d'exécution, ou mieux, exécutées en dehors de la partie embarquée, ces librairies ne posent aucun problème, bien au contraire. Il est quand même rare que ce qui "arrange" le développeur "arrange" aussi le temps CPU consommé et/ou le footprint... La STL / Boost pour ce qui est à l'échelle de temps de l'utilisateur, OK. Pour ce qui est à l'échelle de temps de la machine, ça dépend.

Certes, je parle là de conditions "aux limites", en dehors du cadre d'utilisation de beaucoup de développeurs, et que beaucoup ne verront JAMAIS. Mais il faut être conscient que ces limites existent et que STL / Boost ne sont pas forcément le meilleur choix possible.
Pour ma part, quand j'ai un problème de performances dans un code utilisant la STL, ça se résout 80% du temps en éjectant ladite STL du chemin critique... Amusant, non ?

[Luc Hermitte]

<totalement HS>

a- Pas vraiment, hélas, et par expérience... Je dirais même que filer la STL comme "référence" à un débutant lui interdit souvent de comprendre comment elle fonctionne réellement en interne, ou ce que cela retire comme charge de développement. Comme je l'ai précisé un peu plus haut, je trouve "dangereux" (et j'en ai des preuves constamment hélas) de laisser des débutants croire que la STL est la panacée intégrale sans leur apprendre à le faire "à la main"...
b- Déjà, parce que quand tu es tenu de compiler en C pour des raisons de contraintes de plate-forme (et non pas en C++), ça pleure. Ensuite, parce que même en C++, la STL n'est pas toujours une bonne idée.

c- La STL (et les templates de façon générale d'ailleurs) sont infects à débugger,
d- ont une fâcheuse tendance à augmenter significativement la taille du code binaire produit (souvent gênant en embarqué), et cèdent systématiquement devant le code "manuel" lorsque l'on gère d'énormes quantités de données fréquemment modifiées (ex : buffers de communication), ou que l'on a besoin de vitesses d'exécutions particulièrement contraintes (gestionnaires temps réel par exemple)...

Note bien que quand je parle de "énormes quantités de données", je parle de centaines de milliers d'entrées pesant chacune plusieurs kilo-octets, pour une taille totale flirtant avec le gigaoctet, et ayant en moyenne une durée de vie de quelques millisecondes... Quand en plus tu mets là-dessus un système de priorités, je te promets qu'utiliser la STL va plus te plomber qu'autre chose, ne serait-ce que parce qu'elle ne saura JAMAIS créer les "bons" index d'elle-même.

e- Et si c'est pour finir par transformer des std::map en collections de std::vector de tailles statiques, autant utiliser un bon mieux "new", tu ne crois pas ?

a- Le débutant, quand il débute avec l'Ada, on ne lui demande pas de comprendre comment le compilo met en oeuvre les in/out, ou comment il gère les tableaux contraints. Par contre, il arrive un moment où il cesse d'être débutant et passe à d'autres langages où il est important de comprendre ces mécanismes. Pourquoi il devrait en être autrement en C++?
Je préfère passer derrière un code robuste et maintenable pour l'optimiser (quand et où cela s'avère nécessaire), que de passer derrière un code instable qui tient tout juste les perfs.

b- c'est pour cela que je ne me considère pas comme un développeur C, même si je saurai m'en sortir.

c- A iso-fonctionnalité, je préfère débugguer des templates aux macros.

d- autant que si le service utilisé avait été implémenté à la main. C'est particulièrement vrai pour les vecteurs comparés aux tableaux. Pour les structures plus complexes, il y a toujours moyen d'encapsuler un std::leconteneurquivabien<void*> dans une structure qui recaste automatiquement (ce que fait le Java). J'estime que quand on sait faire ça en C, on devrait aussi savoir le faire en C++.

e- (s/new/new[]/)
Certainement pas. Si on n'a pas besoin de la réallocation ou du RAZ sur allocation, on peut toujours encapsuler new dans un scoped_array, mais le résultat restera chez moi une classe template, et surtout RAII. Un new[] seul, jamais!
Et à propos de reallocation, en temps réel, je préfère mon std::vector::resize à realloc. Non seulement je tiens les perfs, mais en plus le code est plus simple à maintenir qu'avec realloc -- combien savent s'en servir correctement ?

</>

[Mac LAK]

a- Le débutant, quand il débute avec l'Ada, on ne lui demande pas de comprendre comment le compilo met en oeuvre les in/out, ou comment il gère les tableaux contraints. Par contre, il arrive un moment où il cesse d'être débutant et passe à d'autres langages où il est important de comprendre ces mécanismes. Pourquoi il devrait en être autrement en C++?

Mauvaise comparaison. Je dirais plutôt qu'avant d'utiliser algorithm::sort() ou qsort() pour un tri, c'est utile de savoir l'implémenter soi-même. Voire de s'être cassé les dents avec un tri à bulles qui n'en finissait pas. Quelques bonnes bases d'algo ou de processus "élémentaires" n'ont jamais été nuisibles, bien au contraire.

La STL implémente des choses que j'appelle "élémentaires" en terme de stockage de données. J'ai vu un peu trop de débutants croire que mettre une std::string comme "index" d'une std::map était une bonne idée parce que c'était "pratique", que ça ressemblait à ce que l'on voit couramment en langages interprétés, et hélas sans vraiment voir ce que ça impliquait derrière en terme de performances...
Pour maintenir en mémoire une configuration utilisée 2 à 3 fois par seconde, c'est pas gênant. Ça l'est plus dans un chemin critique. Toujours se méfier de ce qui semble faciliter un peu trop le développement...

c- A iso-fonctionnalité, je préfère débugguer des templates aux macros.

Ni l'un, ni l'autre pour ma part. Pour ma part, les deux sont à réserver à des cas très précis où la nature de l'implémentation (template et/ou macro) ne risque pas d'impacter la maintenabilité.

d- autant que si le service utilisé avait été implémenté à la main. C'est particulièrement vrai pour les vecteurs comparés aux tableaux. Pour les structures plus complexes, il y a toujours moyen d'encapsuler un std::leconteneurquivabien<void*> dans une structure qui recaste automatiquement (ce que fait le Java). J'estime que quand on sait faire ça en C, on devrait aussi savoir le faire en C++.

Attends de tomber un jour sur un code où gagner des indirections de pointeurs aura une incidence notable...

Quant ta STL ne te sert plus qu'à utiliser des std::vector parce que c'est le seul truc à peu près sans aucun overhead, quelle en est l'utilité ? Surtout quand les tableaux sont alloués à l'initialisation du programme, de taille fixe, et qu'ils ne sont détruits qu'en fin de processus...

Et à propos de reallocation, en temps réel, je préfère mon std::vector::resize à realloc. Non seulement je tiens les perfs, mais en plus le code est plus simple à maintenir qu'avec realloc -- combien savent s'en servir correctement ?

Realloc ? Temps réel ? Gni ?
Nan, buffers dimensionnés au maximum systématiquement : perdre du temps à réallouer de la mémoire, c'est du suicide de temps CPU... J'avais bien précisé : "tailles statiques".


Chacun voit midi à sa porte, bien entendu, mais pour moi le C++ n'est qu'une façon pratique d'éviter de passer des pointeurs de structures à chaque fonction, et/ou de truffer le code de pointeurs fonctionnels.
Bref, assouplir la POO en C "pur" (qui est une vraie usine à gaz), mais j'utilise ce qui me sert dans le langage sans prendre ce qui me complexifie le boulot et/ou alourdit le résultat final (footprint, code source, temps CPU, ...). Il m'est même arrivé de péter du C++ pour le passer en "C-like" juste pour gagner du temps de compilation, les performances étant similaires entre les deux implémentations dans ce cas précis...

Je ne suis un "intégriste" ni du C, ni du C++, ni du 100% procédural, ni du 100% objet. J'utilise les uns ou les autres indifféremment en fonction de mes besoins, mon code a toujours été maintenable, documenté, et en général bien optimisé. Sûrement parce que je fais souvent soit du code très transversal (faire communiquer des modules n'ayant parfois rien en commun : ni le langage, ni la plate-forme), soit du code vertical (communication du haut niveau vers le bas niveau et réciproquement). Ce qui se résume souvent à faire communiquer des modules en C++ très haut niveau avec des trucs collés au hard, écrits en C "système".

Dans ce genre de situation, on s'adapte assez vite, et sur des compilateurs C/C++, rejeter l'autre langage m'a toujours semblé être une balle que l'on se tire soi-même dans le pied... Je préfère construire un module "hybride" moitié C, moitié C++ mais très efficace plutôt que faire le "puriste" et commencer à vouloir faire communiquer les deux par une socket sur la boucle locale (véridique, déjà vu une telle proposition, hélas...).

[maxim_um]

Note bien que quand je parle de "énormes quantités de données", je parle de centaines de milliers d'entrées pesant chacune plusieurs kilo-octets, pour une taille totale flirtant avec le gigaoctet, et ayant en moyenne une durée de vie de quelques millisecondes... Quand en plus tu mets là-dessus un système de priorités, je te promets qu'utiliser la STL va plus te plomber qu'autre chose, ne serait-ce que parce qu'elle ne saura JAMAIS créer les "bons" index d'elle-même.

.../...

La STL / Boost pour ce qui est à l'échelle de temps de l'utilisateur, OK. Pour ce qui est à l'échelle de temps de la machine, ça dépend.

Certes, je parle là de conditions "aux limites", en dehors du cadre d'utilisation de beaucoup de développeurs, et que beaucoup ne verront JAMAIS. Mais il faut être conscient que ces limites existent et que STL / Boost ne sont pas forcément le meilleur choix possible.
Pour ma part, quand j'ai un problème de performances dans un code utilisant la STL, ça se résout 80% du temps en éjectant ladite STL du chemin critique... Amusant, non ?

Propose un exemple concret, parce que là ton histoire tient du roman de fiction inachevé. Franchement, avec les compilateurs actuels, même l'assembleur n'est plus requis. Pour ce qui est du module embarqué qui gère des millions de données en quelques millisecondes, à l'«ESA» ils ne connaissent pas. Ne le prends pas mal, mais je me demande si tu n'as pas regardé «Matrix» avant de poster. Enfin, la seule chose qui pourrait entrer dans ce contexte c'est une «mainframe», mais dans tous les cas, ça n'a rien à voir avec ce que tu sembles décrire. Pour moi, la meilleure des optimisations se fait au niveau de l'algorithme, le reste, comme le «décalage de bits» par exemple, ce n'est que de la micro-optimisation. Là vraiment, sans un exemple concret, je ne vois pas où tu veux en venir.

[Mac LAK]

Propose un exemple concret

Je te parle de circuits presque complètement câblés, où des FPGA / ASIC effectuent la plus grosse partie du traitement séquentiel, et où un processeur "normal" embarqué doit effectuer la prise de décision impliquant telle ou telle option câblée, ce qu'il ne peut faire qu'en prenant tout ou partie des informations dans sa propre mémoire tout en les conservant plus ou moins longtemps à disposition pour du monitoring.

Comme par exemple l'acquisition / stockage simultanés de plusieurs liens gigabits Ethernet. Ou, dans la même veine, l'acquisition / stockage de dizaines (pour ne pas dire "centaines") de bus de terrain.

Voilà pourquoi je dis que la plupart des développeurs ne verront jamais ce cas.

Il existe cependant, et ça me gave toujours autant de voir un débutant ou stagiaire arriver, être infoutu de faire une allocation sans aller jardiner le thread d'à côté parce qu'il n'a pas son garbage collector et/ou "sa" librairie pour assistés habituelle.

Et tout ça parce qu'un prof déconnecté de la réalité lui a un jour dit qu'avec Java, on faisait tout et qu'il n'y avait plus besoin d'apprendre des bases d'informatique comme la gestion des pointeurs, les algos élémentaires et autres "fioritures" qui n'existent pas forcément sur toutes les plate-formes. Sans même parler du fait qu'un langage de très haut niveau n'est absolument pas adapté à tout et n'importe quoi, bien entendu.

[Jean-Marc.Bourguet]

Voilà pourquoi je dis que la plupart des développeurs ne verront jamais ce cas.

Il existe cependant, et ça me gave toujours autant de voir un débutant ou stagiaire arriver, être infoutu de faire une allocation sans aller jardiner le thread d'à côté parce qu'il n'a pas son garbage collector et/ou "sa" librairie pour assistés habituelle.

Les profs n'ont déjà pas le temps de voir tout ce que la plupart des développeurs rencontreront, et tu voudrais qu'ils abordent des situations que la plupart ne rencontreront pas? J'ai une bonne série de choses à voir avant.

Il y a une chose qui me gave plus que des débutants arrivant en croyant tout savoir et en se prétendant experts, ce sont ceux qui s'attendent à ce que les débutants sachent réellement tout et soient de vrais experts.

Entre l'attitude "il faut réutiliser LAPACK" pour faire une multiplication de deux matrices d'ordre 2 et "il faut tout redévelopper soi-même à commencer par la libc", il y a un juste milieu; et celui-ci va dépendre du contexte dans lequel on est.

(Ceci dit, suivant le cursus, je m'attends à ce qu'un programmeur ait des notions de gestion de mémoire plus poussée que "on laisse faire le GC" même si c'est une attitude raisonnable dans plus en plus de cas).

(En passant, la gestion des charsets, c'est certainement pas un sujet que j'aurais mis comme pierre angulaire d'un défi -- et je suis d'accord avec ceux qui pensent que c'était le seul point où une recherche était nécessaire --, plus je regarde, plus je trouve que la situation normalisée est confuse.)