- la standardisation du C++
- les évolutions potentielles du C++ : bibliothèques standards, ramasse-miettes...
- la position de C++ par rapport à Java et C#
![[fr]](../images/fr.png)
Interview (2921 hits)
> Lire la dépêche (161 commentaires, moyenne: 3,2).
Vous avez demandé le commentaire #117142.
Run by 
Cette page a été générée par Templeet en 0.2981s (dont 0.0225 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
[+] c++ su><or
de toute facon ls c++ n'est qu'un espece de surcouche mal foutu du c, C'est vraiment pas ce qu'on fait de mieux dans la serie des language objets.
meme l'objective C c'est mieux
Si on veut faire de l'oo propre faut prendre des languages propres du genre effel
bon -1 pour lancer de troll abusif :-)
[+] [^]Re: c++ su><or
.............
.............
Non, je marcherai pas dedans !
Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libre)
[+] [^]Re: c++ su><or
Pffff, arrete de troller toi, on t'a vu.
Tu me range ce c++ de merde. Tout le monde sais
que c'est pourri.
[+] [^]Re: c++ su><or
VIVE LE GOTO++
Ce merveilleux langage a été implémenté tout récemment d'une nouvelle fonction compatible avec les anciennes versions du goto++ !
Etonnant non ?
Cette fameuse fonction est :
GOTO error
Fallait y penser ;)
Bientôt une implémentation pour le C++ ?
[+] [^]Re: c++ su><or
Pour répondre à ton troll abusif, un autre:
Le C++, c'est comme le C, il y a des milliers de librairies que personne ne sait utiliser à fond et que leurs concepteurs annoncent "standard". Résultat : Ca pullule à mort et tout le monde réinvente la roue à chaque fois ou y va de sa "petite" lib.
A bas le C et le C++ !!!
Ceci dit, ce serait bien cool si les libs standards étaient un peu plus fournies (et imposées d'ailleurs).
[^]Re: c++ su><or
Je trouve la librairie standard (STL) déjà assez bien fournie et bien foutue. Elle est rapide à maîtriser et depuis que je l'utilise je gagne du temps en développement et je trouve mon code plus facilement lisible après quelques mois d'abandon...
Il existe un excellent bouquin gratos sur le C++ contenant de nombreux chapitres très instructifs, écrits avec une approche pédagogique à l'adresse suivante :
http://www.bruceeckel.com(...)
Ca c'est écrit en anglais.
En français on a (en GNU FDL) : http://casteyde.christian.free.fr/cpp/cours/index.html(...)
Je ne l'ai pas encore lu entièrement, mais j'ai trouvé l'approche assez bonne pour le conseiller. Il y a évidemment une partie sur la STL.
[^]Re: c++ poa....
Je trouve aussi (pour l'avoir longtemps utilise) que la STL apporte beaucoup de facilites. Elle demande un petit investissement, mais les concepts de conteneurs et d'iterateurs sont vraiment interessants/utiles.
Un guide de reference est disponible la:
http://www.sgi.com/tech/stl/(...)
On peut cependant regretter qu'il manque des pointeurs intelligents (autoptr est bien mais pas toujours)... Comme "bonne librairie" on peut trouver la lib boost ( www.boost.org ), elle fournit pleins de trucs (dont des ptrs intellignents) qui ont vocation a etre introduit dans le standard pas la suite.
[^]Re: c++ poa....
As tu réussi a faire utilisé boost dans une très grosse structure ?
Si oui : avec qu'elles arguments ?
J'ai un collègue que ne parle que de boost, mais c'est percu comme un gadget.
[^]Re: c++ poa....
Non et pour cause j'ai jamais travaille pour ou dans une grosse structure. J'ai utilise boost pendant ma these pour developper quelques trucs dont j'avais besoin.
L'argument le plus "simple" est que c'est dans l'esprit de la lib standard et que ca ajoute certains trucs qui manquent, sinon c'est bien portable et bien maintenu.
[^]Re: c++ poa....
L'argument le plus "simple" est que c'est dans l'esprit de la lib standard et que ca ajoute certains trucs qui manquent, sinon c'est bien portable et bien maintenu.
C'est à dire que boost est réalisé en grande partie par des types qui font aussi partie du comité de normalisation C++; donc Boost suit bien sûr «l'esprit» de la STL, mais surtout, est considéré un peu comme un laboratoire d'idée, une espèce de «pré-STL» si on veut, plusieurs libs de boost sont candidates à une future normalisation dans la STL.
Il y a certaines libs dans boost qui valent le coup d'oeil, par exemple regex pour les expressions régulières.
[^]Ca trolle déja sec dans l'interview
Considérez-vous le succès de KDE (développé en C++), et la rapidité de son développement (face à un Gnome développé en C qui stagne) comme une démonstration de la supériorité de C++ sur de tels développements ?
Ils nous ressortent le vieux troll gnome/kde de derriere les fagots. Sont pas aware chez DR.
[^]Re: Ca trolle déja sec dans l'interview
Ouin tu m'a pris de vitesse !
ps je doit etre un peu zarb moi: je supporte pas KDE et je tolere GNOME, et j'aime le C et le C++ (quoique je prefere le C++ dans certains cas et le C dans d'autre). Docteur, suis je malade ?
Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libre)
[+] [^]Re: Ca trolle déja sec dans l'interview
Oui tu es fou, les gens cens'es ne peuvent pas
apprecier le C++
[+] [^]Re: c++ su><or
Pour parler d'une telle façon du C++, tu ne dois pas vraiment connaître ce langage.
Essayes par exemple de coder en C l'algo cité dans l'article de B. Stroustrup
On verra si tu continues après à garder le même opinion !
[^]Re: c++ su><or
Tu parles du truc qui trie les mots ? C'est pas le langage qu'il utilise là, mais les libs...
En C avec la GLib on fait pareil en à peu près autant de lignes, je vois vraiment pas la différence, à part que la lib standard C++ intègre des trucs qui se trouvent ailleurs en C (dans la GLib par exemple)
[+] [^]Re: c++ su><or
Oui, avec la glib ... qui est une lib en plus du C. fait ca avec la glibc par contre !
L'interet c que toutes les implementations standards de C++ peuvent utiliser cet algo. ce qui n'est pas vrai d'une appli C/glib qui n'est pas utilisable sur tout les systemes.
Il [e2fsck] a bien démarré, mais il m'a rendu la main aussitot en me disant "houlala, c'est pas beau à voir votre truc, je préfèrerai que vous teniez vous même la tronçonneuse" (traduction libre)
[^]Re: c++ su><or
Euh... tu sais sur combien de systèmes elle est portée la GLib ? Et sincérement, porter la GLib sur un nouveau système c'est _beaucoup_ plus simple que de porter un compilo C++ ou la STL, alors bon...
Si on dit "tel langage est meilleur parce que son API de base est plus complète" on est bien mal barrés...
[^]Re: c++ su><or
Si on dit "tel langage est meilleur parce que son API de base est plus complète" on est bien mal barrés...
La grande leçon de C++, c'est précisément qu'un langage doit avoir une librairie standard aussi complète que possible. Si C++ avait eu tout de suite la lib standard qu'il a maintenant, ça aurait évité énormément de merdes.
C'est bien pour ça que Java et C# ont été designé dès le départ avec des libs standard très complètes.
Donc oui, bien évidemment, un langage est meilleur si son API de base est plus complète.
[^]Re: c++ su><or
Sauf que c'est dur de considerer qu'une API puisse faire partie d'un langage. Enfin je dis ça, je dis rien. Le coup de l'"API de base", je découvre, mdr.
Ensuite pour Java, quand on parle des libs, on parle de "plateforme" Java (lang+lib+jvm), itou pour C++ où BS parle de "framework".
Déjà faites bien la distinction entre le langage et le framework, et vos trolls seront plus beaux, plus forts.
[^]Re: c++ su><or
Sauf que c'est dur de considerer qu'une API puisse faire partie d'un langage.
Essaie, tu vas voir ça vient tout seul.
Ce qui compte c'est ce que tu as à ta disposition en standard pour développer une fois que tu as installé le langage.
Après, chipoter sur "ça c'est dans le langage, ça c'est dans la lib", juste pour pouvoir dire "ah mais oui mais évidemment C c'est aussi facile que Java y a qu'a prendre les bonnes libs", c'est bien pour faire le neuneu sur linuxfr mais ça fait pas avancer ton code quand tu dois vraiment faire un truc qui marche.
[^]t'es trop ouf toi...
Ben j'essaye, mais plus j'essaye plus je pense que tu es à coté de la plaque. Ou alors il faudrait redéfinir ce qu'est un langage, mais j'ai pas le temps là. En plus une API c'est avant tout une interface, donc lier une API à un langage c'est du suicide. Ou alors il faudrait redéfinir le concept d'interface, oui mais j'ai pas le temps là. Nan, tu délires là, tu me trolles ou tu me charries ?
Si tu veux faire avancer ton code, le plus rapide c'est d'arreter les trolls et d'utiliser les design patterns sur une plateforma adéquate et le langage adapté aidé par un framework solide. Java c'est plus qu'un langage, et STL c'est en plus du C++ mais intimement lié à C++. Question de relations, de jargon.
[^]Re: t'es trop ouf toi...
Ben j'essaye, mais plus j'essaye plus je pense que tu es à coté de la plaque
Non, je suis pragmatique. std::vector<> c'est du C++. Tu peux dire "c'est pas du C++, c'est une lib", en pratique ça fait partie de ce que tu peux utiliser en standard quand tu fais du C++. Pareil pour les libs Java.
Si tu veux faire avancer ton code, le plus rapide c'est d'arreter les trolls et d'utiliser les design patterns sur une plateforma adéquate et le langage adapté aidé par un framework solide.
T'es consultant dans la vie réelle ? :-)
Java c'est plus qu'un langage, et STL c'est en plus du C++ mais intimement lié à C++.
Oui, on est d'accord.
[^]Re: t'es trop ouf toi...
« et STL c'est en plus du C++ mais intimement lié à C++. »
Non ça en fait partie, même cas que Java. (en fait Java comprend aussi des choses en plus, mais ça ne concerne plus la bibliothèque).
Ou alors, veux-tu dire de la même manière que printf() ne fait pas partie du C ? Évidemment on peut réduire un langage à une grammaire, sa sémantique, mais aucune norme de langage ne se limite pas à ça.
Regarde par exemple sur les newsgroups fclc/fclc++ : tout ce qui concerne les bibliothèques standard de chacun de ces langages est valable. Or c'est plutôt le genre de groupe ou on ne trainera pas à te dire d'aller poster ailleurs si tu t'écartes du langage.
[^]Re: t'es trop ouf toi...
A l'origine la C n'a pas de bibliothèque, mais une bibliothèque a toujours été livrée avec
les compilateurs, elle est devenu standard est a été standardisées par la suite.
Alors que pour le C++, il y a toujours eu une lib standard (ne serait ce que c'elle du C).
Il est plus facile en C de se passer de la lib, alors que pour le C++ il faut bien connaître.
Le C++ est beaucoup plus dépendant de ca lib que le C.
[^]Re: c++ su><or
Une autre grande lecon de C++ : c'est mieux quand on a le source.
Version longue : Avec le C, tu peux linker des libraries et des objets produits par des compilos différents. En C++, la plupart du temps ce n'est pas possible, parce que, entre autre, la décoration des noms n'est pas standardisée.
Et quand un éditeur ne fournit sa librarie en binaire que pour le compilo natif de la plateforme (au hasard, CC sur Solaris), pas moyen de l'utiliser avec g++ (qui est nettement moins cher ;) Bien sur, si l'éditeur fournit le source, on peut recompiler.
Conclusion: c'est mieux quand on a le source.
[^]Re: c++ su><or
Non, c'est mieux quand on spécifie l'ABI (encore un truc que Java et C# ont fait).
Paradoxalement, C++ a beau être énorme, il n'a pas spécifié assez de choses (la lib standard et l'ABI).
[^]Re: c++ su><or
Le problème de l'ABI, c'est que c'est dépendant de l'architecture processeur (à moins bien sûr de tout foutre sur la pile avec un alignement énorme genre 128 bits - mais même là il faut encore définir quel registre fait office de pointeur de pile, ou de tas). Java et Cchose produisent un unique type de bytecode en sortie, donc c'est plus facile pour eux.
[^]Re: c++ su><or
Ah, je savais bien qu'il y avait une bonne raison pour laquelle ça n'avait pas été fait. Ça plus les vendeurs de compilo qui se tirent la bourre pour faire leur sauce.
[^]Re: c++ su><or
Bin non, regarde :
OnOn est barré correctement,non ?
[-1etjesorsencourant]
[^]Re: c++ su><or
Euh... tu sais sur combien de systèmes elle est portée la GLib ? Et sincérement, porter la GLib sur un nouveau système c'est _beaucoup_ plus simple
D'un autre côté, il y a très peu d'applis qui utilisent la glib, en dehors d'applis graphiques.
En pratique, sur les 1800 applis portées sous OpenBSD, seule une poignée (5 environ) dépendent sur la glib sans utiliser X, et la seule que je connais est irssi.
Cela tend bien à prouver qu'en C, on préfère en général réinventer la roue, plutôt que de se reposer sur des libs existantes.
[^]Re: c++ su><or
Et sincérement, porter la GLib sur un nouveau système c'est _beaucoup_ plus simple que de porter un compilo C++ ou la STL, alors bon...
Ah. Je manque à voir la logique dans ce pseudo-argumentaire. Notament l'incohérente comparaison entre la portabilité de la glib (une bibliothèque) et, diable, un compilateur.
La glib utilise le C, la STL le C++, où est donc le problème?
Pour reprendre tes propos. Euh... Tu sais sur combien de systèmes est porté GCC? Généralement, il y a un compilateur C++ qui vient avec...
[^]Re: c++ su><or
Euh... Tu sais sur combien de systèmes est porté GCC? Généralement, il y a un compilateur C++ qui vient avec...
Tsss, faut pas le dire, voyons, tu vas les perturber.... Déjà qu'on essaie de leur faire accepter progressivement que leur *nix permet de faire des threads en plus du fork() tellement moderne.... ;))
(-1, car n'importe quoi)
[^]Re: c++ su><or
T'as oublié le -1, et oui, c'est n'importe quoi, tu vas me dire aussi qu'on a pas de threads en C ou en C++ parce qu'il n'y en a pas dans l'API standard du langage ? Ben oui, c'est du même niveau ce que vous me dites là...
Avoir des fonctionalités comme les tables de hachage, les listes chainées, ... dans une lib externe au lieu de les avoir dans le langage lui-même, c'est beaucoup mieux, ne serait-ce que parce que si tu veux développer dans un environement minimum (comme pour faire de l'embarqué), tu peux; que si tu veux utiliser une autre implémentation c'est bcp plus simple, ...
[+] [^]Re: c++ su><or
Sauvons le monde de l'horrible C++ la glib doit faire parti de la nouvelle norme du C.
-1 car beaucoup mais beaucoup trop gros.
[^]Re: c++ su><or
En C avec la GLib on fait pareil en à peu près autant de lignes
Vas-y, fais voir le code.
[^]Re: c++ su><or
La grosse différence entre la STL et la GLib c'est que la STL est fournie avec le compilateur C++. De nos jours (et depuis plusieurs années d'ailleurs) cette bibliothèque est donc disponible sur tous les compilos proprios ou libres. C´est comme le stdio.h, etc. du C.
Cela présente l'avantage de pouvoir travailler n'importe où en utilisant une bibliothèque que tu connais bien et maîtrises sans avoir à en compiler une, à la tester, etc.
[+] [^]Re: c++ su><or
Mais oui bien sûr, donc intégrons tout ce qui concerne le graphisme, le son, la reconnaissance vocale, les formats d'images, et la décompression de vidéo en standard dans les langages, comme ça on les a partout...
[^]STL = Standard Template Library
Rien à voir.
La STL est une librairie très générale (conteneurs, flux d'e/s...). Avec évidemment tu peux faire tout ce que dis (décompression, graphisme). Faudrait voir à ne pas amalgamer.
Imagines-tu un C sans fonctions d'entrées/sorties par exemple ? Ca limiterait grandement son utilisation par exemple.
On dirait plutôt que tu ne sais pas ce qu'est la STL et que tu as juste envie de la descendre ! Libre à toi remarque.
[^]Re: STL = Standard Template Library
AMA, pour convaincre de l'interet de la STL dans un premier
temps j'aurais tendence à dire qu'elle facilite l'écriture d'algo
plus ou moins complexes avec un minimum d'expressions. Au début
quand on parlait conteneur ou chinois je voyais pas la différence :)
[+] [^]Re: c++ su><or
Ha ha, mais c'est pas compil'e pour une bonne partie de la lib car contenue dans des headers ... c'est pour ca qu'un programme C++ met 3heures a ce compiler ...
Enfin bon ...
[^]Re: c++ su><or
La différence est qu'en C++ tu le fais avec des conteneurs (templates), alors qu'avec la glib tu fais ça avec des pointeurs sur fonction. En pratique, le code généré en C fait des indirections à gogo, alors que dans le C++ tout peut être optimisé à fond.
[+] [^]Re: c++ su><or
Comment expliques-tu alors qu'un code généré par un compilo C soit toujours plus petit et rapide que l'équivalent en C++ ?
[^]Re: c++ su><or
Si tu compiles du C avec le compilo C de X alors tu auras un code au moins aussi rapide que si tu le compiles avec le compilo C++ de X, cela me parait normal (ou alors X a laisse tombe son compilo C).
Sinon, ca depend du code, les templates permettent de faire du code tres efficace quand c'est necessaire. Mais la vitesse du code est rarement un critere, la vitesse d'ecriture est souvent plus importante.
[^]Re: c++ su><or
On ne l'explique pas, parce que c'est faux (à moins d'avoir un compilo C++ vraiment pourri).
Ou alors tu as une notion très particulière de ce qui est "équivalent".
[^]Re: c++ su><or
Non non, il y a vraiment des compilos C++ vraiment pourris. En fait ce ne sont pas des compilos, juste des merdes qui traduisent le C++ en C. Donc dur d'avoir de l'optim C++ à la compil, et au debug tu prends tes jambes à ton coup...
[^]Re: c++ su><or
Ca c'était y a dix ans, quand t'as découvert l'existence de C++ alors que t'essayais de reprogrammer emacs en Prolog. Depuis, les outils ont évolué, Johnny....
[^]Re: c++ su><or
pas dix ans, aujourd'hui, chez un grand fondeur européen qui commence par S et finit par M, et qui se la pete à la télé quand le permier ministre vient inaugurer en grandes pompes leur dernière usine (en retard d'une génération ;)...
[+] [^]Re: c++ su><or
peut etre justement parce que il ne l'est pas!
cf qsort vs. sort
[^]Re: c++ su><or
Rapide c'est ton affirmation, pour la taille cf nm
[^]Re: c++ su><or
La différence qu'en C, ta fonction g_list_length() qui te renvoie la taille d'une liste chainée (ou tout autre fonction de la GLib), elle est une fois et une seule fois dans /usr/lib/libglib.so.2.0.1 et une et une seule fois en mémoire.
En C++, ta fonction elle se trouve une fois par fichier cpp et par type de données manipulé.
Après, il ne faut pas chercher loin pour voir tous les inconvénients de la méthode C++: polution du cache, de la TLB [1], de la mémoire, du disque dur, temps de compilation affreusement longs, nécessité de recompiler toutes les application si un bugfix ou une mise à jour est appliqué dans la lib, ...
Sans compter que la méthode C à base de pointeurs de fonction permet de faire des choses qui ne sont pas réalisables avec la méthode C++, car le type n'a pas besoin d'être connu lors de la compilation.
[1] Translation Look-aside Buffer, table interne au processeur qui cache les converions addresse virtuelle => addresse physique.
[^]Re: c++ su><or
Sans compter que la méthode C à base de pointeurs de fonction permet de faire des choses qui ne sont pas réalisables avec la méthode C++, car le type n'a pas besoin d'être connu lors de la compilation.
Du genre ?
Reste la possibilité de faire dériver tes classes d'une même classe root.
Ho et puis de toute façon, ObjectiveC + GNUstep ro><or . Au moins c'est du vrai objet et un vrai bon framework objet.
C++ c'est bien, mais bon... Enfin ceci dit y'a pas photo entre C++ et C ! ne charrions pas quand même.
[^]Re: c++ su><or
Enfin moi je dis: vivement que le patch de mac pour gcc soit accepte... comme ca on pourra jouer avec l'objective-c++ :-)
[^]Re: c++ su><or
Disons que d'un point de vue GNUstep c'est bien car on pourra avoir par exemple chimera sous linux ;)
D'un point de vue purement langage c'est pas indispensable, mais c'est pratique (coopérations c++/objectiveC)
[^]Re: c++ su><or
Mais vous etes completements fous...
melanger du C++ avec de l'objective C, c'est bien une idee de programmeur C++ ca, car cela n'a aucun interet. Franchement quand on utilise l'Objective C, on peut se passer des problemes du C++....
C'est peut etre pour developper des machins KDE en Objective C ?
[+] [^]Re: c++ su><or
melanger du C++ avec de l'objective C, c'est bien une idee de programmeur C++ ca, car cela n'a aucun interet.
Grandis un peu.
Entre autres interêts, il n'y a pas de toolkit graphique pour Objective C (à part celle de Mac OSX bien sur, mais ailleurs...), et les wrappers GTK+ ont été abandonnés depuis longtemps parce que personne ne les utilisait. Ou trouve un bon parser XML en Objective C par exemple.
Ensuite, compare la taille minimale d'une classe Objective C avec celle d'une classe C++. Si tu dois manipuler un grand nombre de petits objets, il est pratique de t'affranchir du runtime ObjC.
[^]Re: c++ su><or
polution du cache
Sans m'y connaitre a fond dans les caches, je trouverais logique que si tu appliques un algo a N elements:
- il va y avoir une mise en cache une seule fois du bout de code (du style si c'est un sort) sur lequel on va boucler
- pour les donnees, pas de pitie. Si c'est des tableaux ok (donnees contigues en memoire). Si c'est des listes chainees tant pis. Si t'as vraiment besoin de perfs de la mort, tu peux toujours t'adapter en C++.
En C++, ta fonction elle se trouve une fois par fichier cpp et par type de données manipulées.
Deja, qu'appelles-tu une fois ? Une fois par fichier objet ? OK. Mais ca c'est seulement a la compil. Une fois passe au link, les fonctions template non inlineees (imagine que std::sort<Voiture> soit trop gros pour que le compilo puisse le faire inline) sont en un seul exemplaire dans l'exe.
la méthode C à base de pointeurs de fonction
La methode C++ te laisse le choix:
- tu veux des perfs qui tuent avec les templates qui "inline" tes algos, c'est bon
- tu veux la "flexibilite" (hum) dont tu parles avec le C ? Pas de probleme, le C++ fait ca aussi. C'est tres simple de refaire par exemple une fonction qsort a base de fonction std::sort...
Pas de bureau 3d libre sans drivers libres!
[^]Re: c++ su><or
Bon alors toi, t'a rien compris ...
En C++, un template genere des fonctions specifique a chaque type de donnees, donc code different, donc entre l'appel a la meme fonction pour le type X et le type Y, il y aura un defaut de cache et le processeur devra refaire le chargement, decodage de la fonction.
Donc au link, les fonctions peuvent etre inlinees, donc dupliquees, et cela prend plus de place en rame qu'une fonction completement generique et cela va aussi dans le sens de ce qui est ecrit au dessus.
Tout le probleme du C++ c'est de ne pas pouvoir vraiment supporter le typage dynamique (celui qui est completement inconnu a la compilation, ce que permet l'objective C)
[^]Re: c++ su><or
En general ce qui pose le plus de probleme au niveau des caches c'est les donnees ! C'est pas parceque t'as une fonction template qui va etre exprimee (en assembleur) quatre fois (parceque tu tries des entiers, des floats, des string, et des dates pex) que cela tuera les perfs ! Un defaut de cache n'est pas genant, c'est la repetition de defaut de cache qui tuent le perfs. A mon avis l'indirection est ici beaucoup plus couteuse !
Pour le typage, oui C++ est plutot axe typage statique, cela a toujours etait voulu parce que cela a des avantages (bug a la compil plutot qu'a l'exec pex !), mais C++ supporte le typage dynamique (voir dynamic_cast<T>).
ps: moi je pense que c'est toi qui n'a rien compris.
[^]Re: c++ su><or
Tout ce que je voulais dire, c'est que la mon avis les fonctions inline generes par les templates ont plus de benefice dans les perfs (pas d'indirection dues au typage dynamique) que d'inconvenients (problemes de cache).
Pas de bureau 3d libre sans drivers libres!
[^]Re: c++ su><or
Si tu reecris le meme algo dans chaque classe uniquement parce que le type change, pas etonnant que tu dises que C++ c'est de la merde.
Mais dans ce cas c'est parce que t'as rien compris a l'approche objet.
Les fonctions virtuelles c'est pas la pour faire joli.
[+] [^]Re: c++ su><or
T'as rien compris à mon message, j'ai pas dit que je réécrivais l'algo, mais qu'avec les templates le compilo générait le code à chaque fois que l'algo est appelé justement au lieu de l'avoir une fois pour toute dans une lib.
[^]Re: c++ su><or
Justement, avec C++ t'as le choix entre:
- templates --> bouffe un peu plus de place car specifique a chaque type de donnee mais le code est optimal pour ton type de donnee
- fonctions virtuelles --> bouffe moins de place, le code est identique pour tous les types de donnees, mais est un peu plus lent.
En C, le truc identique aux templates, ca n'existe pas, faut tout te degotter a la main
Le coup des fonctions virtuelles, tu peux magouiller pour faire un truc qui ressemble, mais le resultat est assez difficile a maintenir.
[+] [^]Re: c++ su><or
> - templates --> bouffe un peu plus de place car specifique a chaque type de donnee mais le code est optimal pour ton type de donnee
bouffe _beaucoup_ plus de place, avec des conséquences sur la vitesse d'exécution (cache, TLB, ...) et surtout les autres limitations dont j'ai parlé (absence de compilation séparée, ...)
> En C, le truc identique aux templates, ca n'existe pas, faut tout te degotter a la main
Si, ça fait avec des #define, c'est pas joli joli, mais ça revient exactement au même que les templates, c'est le même niveau de saleté (du code dupliqué lors de la compilation)
[^]Re: c++ su><or
Si les templates te conviennent pas pour des raisons de place, rien ne t'empeche d'utiliser des classes et des methodes virtuelles, t'as l'overhead d'avoir un acces a la vtable, mais ca prend moins de place.
Resultat: en C++, t'as le choix des 2 approches, en C, tu ne peux pas faire l'approche template, et l'approche 'methodes virtuelles' (equivalente a jouer avec des pointeurs de fonctions en C) est bien plus chiante a faire en C qu'en C++ ou le compilo se charge de bcp de choses a ta place.
(me parle pas des define pour des templates, ca donne du code illisible, absolument pas maintenable et t'as 10x moins de possibilites, genre les parametres par defaut,...)
[^]Re: c++ su><or
Non, les méthodes virtuelles sont _très loin_ de permettre tout ce que permettent les pointeurs de fonction, mais alors très loin.
Et c'est justement parce que le compilo fait des trucs d'une manière et que moi j'aimerais bien les faire d'une autre...
Quand au code illisible, les templates c'est assez fort dans ce genre là
[^]Re: c++ su><or
Tu peux toujours utiliser des pointeurs de fonctions en C++ si tu veux.
L'avantage du C++, c'est que c'est (quasiment) un sur-ensemble du C. Il fournit (presque) tout ce que permet le C, et bien plus encore, tout en générant un code aussi optimisé, si le compilo est correct.
Programmer les templates en C avec des macros, j'ai déjà donné. Je crois que je ne referai plus jamais ça.
[+] [^]Re: c++ su><or
Complètement faux, essaie de passer une méthode "char *foo(char *)" là où le compilo attend une méthode "void (*)(void *)" et ça ne marchera jamais, essaie de passer un pointeur sur une attribut ou une méthode d'une surclasse à une méthode d'une sous-clase, ...
Ce sont des trucs qui sont rendus impossibles car ils rentrent en conflit avec les méchanismes objets _très_ limités du C++.
Quand au code aussi optimisé, je l'ai expliqué des dizaines de fois, c'est complètement faux aussi, ou en tous cas avec les compilateurs que j'ai pu tester.
[^]Re: c++ su><or
Si tu passes une methode char *foo(char *) la ou le compilo attend une methode voir (*)void(*), pour moi tu as un bug dans ton code.
J'appelle pas ca de la programmation mais un hack douteux.
Quand a passer un pointeur sur la methode d'une surclasse je vois pas ou est le probleme:
#include<iostream.h>
class CHello
{
public:
CHello() {}
const char* GetName() {return m_Name;}
private:
static char m_Name[20];
};
char CHello::m_Name[20]="CHello";
typedef const char* (CHello::*pmfGetName)(void);
class CHelloWorld : public CHello
{
public:
CHelloWorld() {}
const char* GetName(pmfGetName MyFunc) { return (this->*MyFunc)(); }
};
int main(int argc, char *argv[])
{
pmfGetName FuncName=&CHello::GetName;
CHelloWorld TestClass;
cout<<TestClass.GetName(FuncName)<<endl;
return 0;
}
[^]Re: c++ su><or
> J'appelle pas ca de la programmation mais un hack douteux.
Tu appelles ça comme tu veux...
> Quand a passer un pointeur sur la methode d'une surclasse je vois pas ou est le probleme:
C'est tout l'inverse que je disais moi... passer à une méthode de CHello un pointeur sur une méthode fournie par CHelloWorld, sans que CHello ne connaisse même l'existence de CHelloWorld.
[^]Re: c++ su><or
#include <iostream>
void toto(void *(*f)(void *))
{
f(0);
}
char *titi(char *x)
{
cout << "OK" << endl;
return 0;
}
int main()
{
toto((void *(*)(void *))titi);
}
[+] [^]Re: c++ su><or
J'ai parlé de _méthodes_ pas de _fonctions_
-1
[^]Re: c++ su><or
Complètement faux, essaie de passer une méthode "char *foo(char *)" là où le compilo attend une méthode "void (*)(void *)" et ça ne marchera jamais
Ben non, encore heureux (à moins de caster violemment, mais tu cours au coredump). Et ça ne marchera pas en Java ou en ObjC non plus, ni même en Ruby ou Python (tu aura une exception au runtime si tu essaies d'utiliser la méthode en question).
Au fait, en C++ on utilise plutôt std::string que char*.
essaie de passer un pointeur sur une attribut ou une méthode d'une surclasse à une méthode d'une sous-clase
C'est tout à fait possible, mais pourquoi le faire ? La sous-classe a déjà accès aux méthodes et attributs de la sur-classe. Ça sent très mauvais ton truc. Passer un objet et un pointeur de méthode à une classe complètement différente (genre map()/apply()) ça par contre c'est déjà plus utile, et ça marche aussi.
Ce sont des trucs qui sont rendus impossibles car ils rentrent en conflit avec les méchanismes objets _très_ limités du C++.
Je ne comprends pas. Ce dont tu parles est possible, sauf l'erreur de type qui ne l'est pas pour de très bonnes raisons. Et tu dis que le C est mieux, alors que C n'a même pas ces mécanismes là.
Quand au code aussi optimisé, je l'ai expliqué des dizaines de fois, c'est complètement faux aussi, ou en tous cas avec les compilateurs que j'ai pu tester.
Lesquels ?
[^]Re: c++ su><or
Non, les méthodes virtuelles sont _très loin_ de permettre tout ce que permettent les pointeurs de fonction, mais alors très loin.
Exemple ?
[^]Re: c++ su><or
Tu sais, la magie de C++, c'est que non seulement tu as les templates et les methodes virtuelles, mais tu as aussi les pointeurs de fonction et les pointeurs sur fonctions membres si t'as des besoins hyper-specifique ou bien si tu aimes faire des trucs degueulasses et impossible a maintenir.
Quand aux templates illisibles, c'est a se demander si:
- tu n'as vu que des templates codes par des schtroumpfs
- tu es ivre
- tu sais de quoi tu parles
Les templates sont un procede 10x plus propre que l'equivalent en C(les macros), 10x plus puissant, et qui ont l'avantage d'etre traites par le compilo et non pas par le preprocesseur.
Mon experience perso(je parles meme pas du boulot la) c'est un soft de +100'000 lignes ecrit en C++ pur a 2, qui est oriente perf(moteur de recherche), portable sur freeBSD, IRIX, Solaris, NT et Linux.
C'est pas du 'faux C++' mais du vrai C++ avec une hierarchie de classes, des classes templates,...
Ca fait plus de 9 ans perso que je code en C, et environ 5 ans en C++, je suis bien plus performant en C qu'en C++ et pourtant je me rends compte tres clairement qu'ecrire ce soft en C au lieu de C++ aurait eu pour resultat:
- un nombre de bugs bien plus gros
- un soft tres difficile a maintenir vu la taille et la complexite du soft
- un temps de developpement bien plus long
- une portabilite bien plus difficile a etablir
Quand aux perfs, elles sont tres bonnes, et je doutes tres fort qu'une version en C pur ait ete plus rapide tout simplement car l'ecrire en C aurait ete tellement complique qu'on aurait pas pu optimiser correctement la chose sans faire un merdier pas possible.
Ensuite, j'oses meme pas te parler de ce qu'on fait au boulot, c'est des projets qui depassent les 10 millions de lignes de code, et la tu vois tout de suite a quel point C++ ecrase C pour ce qui est maintenance de code.
[^]Re: c++ su><or
Je passe sur la première partie qui tient plus des attaques personnelles et le diffamation que de l'argumentation.
Je ne jamais dit que les templates étaient plus crades que des #define, mais qu'au niveau des concepts c'est la même chose, et que c'est beaucoup moins lisible qu'un vrai code générique comme on le fait en C.
Ensuite, non, tu ne peux pas utiliser les méchanismes du C (pointeurs et pointeurs de fonction) lorsque tu utilises les méchanismes du C++, cf ce que j'ai dit ailleurs, ça ne marche pas, tu buttes sans arrêt sur les limites que le compilo est obligé de te mettre...
Maintenant, peut-être quoi ça te convient mieux pour je ne sais quelles raisons, mais pour faire du C++ au taf 40h/semaine, je peux t'assurer que tous les jours ou presque je butte sur des trucs qui seraient beaucoup simple à faire de manière élégante en C...
Quand à ce que tu fais à ton boulot, quoi on voit le résultat, bon, sans commentaires ;)
[^]Re: c++ su><or
Je ne jamais dit que les templates étaient plus crades que des #define, mais qu'au niveau des concepts c'est la même chose
Non, les templates sont beaucoup plus puissants et flexibles.
Maintenant, peut-être quoi ça te convient mieux pour je ne sais quelles raisons, mais pour faire du C++ au taf 40h/semaine, je peux t'assurer que tous les jours ou presque je butte sur des trucs qui seraient beaucoup simple à faire de manière élégante en C
Comme quoi par exemple ?
Pour l'instant tu donnes plutôt l'impression de quelqu'un qui fait du C++ sans savoir bien s'en servir.
[+] [^]Re: c++ su><or
> Pour l'instant tu donnes plutôt l'impression de quelqu'un qui fait du C++ sans savoir bien s'en servir.
STP, évite de juger les gens que tu ne connais pas, merci, et c'est valable dans le cas général, pas seulement ici.
-1 car HS
[^]Re: c++ su><or
Je te juge sur les bétises que tu ecris ici, le fait que tu ne répondes jamais quand on te demande d'étayer tes dires avec des exemples ou du code, et ton CV sur ton site qui est celui d'un débutant.
La façon dont tu réponds aux mises en doute de tes compétences est également révélatrice.
[^]Re: c++ su><or
Je suis étudiant donc mon avis ne compte pas et j'ai forcément tord ? Et ben bravo...
décidément... ça devient n'importe quoi ici :(
[^]Re: c++ su><or
Je suis étudiant donc mon avis ne compte pas et j'ai forcément tord ?
Non. Tu es un étudiant, tu n'as pratiquement aucune expérience, et il te reste encore beaucoup à apprendre.
Tu as 2 personnes (moi et pasBill), beaucoup plus expérimentées que toi, qui te disent que tu as tort à propos de ce que tu dis sur C++, un langage que tu connais à peine. Ces deux personnes connaissent C++ bien mieux que toi, et le pratiquent depuis plus longtemps.
Tu préfères continuer de penser que tu as raison, et de rejeter sans refléchir ce que te dit pBpG simplement parce qu'il travaille pour Microsoft. Ça aussi, c'est typique d'un étudiant inexpérimenté.
Si un mec qui n'a jamais essayé Linux t'affirme que Windows est mieux, tu vas le prendre au sérieux ?
[^]Re: c++ su><or
Ca n'a rien a voir avec de l'attaque personnelle, c'est une constatation tiree de :
- ce que fait l'industrie du software en general
- ce que j'ai vecu depuis des annees
- ce que fait Microsoft, boite qui quoi qu'on en dise est tout de meme a la pointe dans un grand nombre de domaines concernant le software
Quand tu bosses sur des projets ou un tas de gens differents vont relire ton code, changer ton code,... tu peux pas te permettre de mettre des trucs vaseux dans ton code que toi seul comprend, quand tu developpes un soft de la taille de Windows, tu peux pas te permettre de laisser chacun faire sa petite cuisine de son cote,...
Les templates SONT efficaces.
Quand aux pointeurs de fonction, ils ne posent aucun probleme en C++, ca MARCHE.
Maintenant, je te ferais juste remarquer un petit truc en passant:
Si tu veux passer un pointeur sur une methode d'une classe fille a une classe parente, c'est que tu code de maniere tres SALE.
Qui te dit que la fonction de la classe fille n'accede pas a des donnees membres de la classe fille uniquement ? La classe parente n'en sait RIEN, et faire un truc de ce genre n'est encore une fois rien d'autre qu'un HACK.
Sinon quand a mon boulot, perso je vois une boite qui a des softs au top niveau dans les domaines OS, mail server, DB server, development tools, ... bref dans la plupart des domaines, et qui arrive a integrer tous ces softs ensemble pour en faire un tout homogene et qui est plus puissant que la somme des qualites de ces produits.
J'attends de voir une autre societe ou des dev libres faire un truc equivalent en complexite et efficacite.
[^]Re: c++ su><or
Bien évidemment je parle du cas où l'objet est de la classe fille, par exemple la classe mère a une méthode apply() qui prend un pointeur sur une méthode et fait des trucs avec, et une méthode de la classe fille veut appeler apply() avec l'une de ses méthodes à elle en paramètre.
Pour le reste, bon, entre les attaques personelles et l'éloge d'une société qui produit AMHA les pires softs ayant jamais existé, surtout d'un point de vue de la sécu (win 9x, IIS, Outlook, IE, ...), il n'y a _rien_
[^]Re: c++ su><or
C'est incroyable ce que tu peux etre borne quand meme....
Va demander aux gens de chez IBM, va demander chez Motorola, chez Sun,... TOUTE l'industrie du software est d'accord la dessus.
Tu as remarque qu'une tres grande partie du code de Mozilla est en C++ ? Tu crois que c'est un pur hasard ?
Tu t'es jamais demande pourquoi BeOS a ete ecrit en C++ ?
Avec ca, toi tu debarques avec aucune experience de developpement sur des projets de grosse taille et tu comptes expliquer a tout le monde qu'ils font n'importe quoi et que tu en sais plus qu'eux la dessus ?
Quand a MS, ils font peut-etre les pires softs ayant jamais existe, il n'empeche que:
- Windows detient les records en rapport perfs/prix du benchmark TPC
- meme chose pour SAP
- il a des capacites de management a distance qui font palir bon nombre de systemes
- DirectX est sans equivalent valable
- COM, WMI,... C'est marrant mais Windows est le seul OS a integrer ce type de technologies, et tout l'OS ainsi que les applications en tirent parti.
SQL Server est dans le top 3 des bases de donnees
Office n'a aucun equivalent, OpenOffice/StarOffice est plus lourd, plus lent, moins complet
...
Developper tout ca, faire que toute cela marche ensemble correctement, que le developpement soit fait en un temps raisonnable et que ce soit maintenable, ca demande certaines competences contrairement a ce que tu peux croire, mais bon, tu es le bienvenu pour aller expliquer a Dave Cutler, Mark Lukovsky et autres comment faire du developpement, apres tout il ont seulement plus de 20 ans d'experience dans le domaine.
Si t'es meme pas capable d'avoir un brin d'objectivite, ca devient inutile de discuter.
[^]Re: c++ su><or
Windows detient les records en rapport perfs/prix du benchmark TPC
C'est pas possible pour la bonne raison que le meilleur rapport perfs/prix est détenu par tous les systèmes qui sont gratuits : linux, *bsd, ... pour ceux là, le rapport est infini...
-1 parce que bon...
[+] [^]Re: c++ su><or
Eh non, car t'as besoin de plus de hardware pour arriver aux memes perfs.
Va donc jeter un oeil sur www.tpc.org, et compares les rapports prix/perfs des 2 systemes Linux et des systemes Windows, c'est un rapport x2
[+] [^]Re: c++ su><or
> TOUTE l'industrie du software est d'accord la dessus.
parce que si l'industrie le fait c'est qu'elle a raison ? si on a plus de x86 c'est que x86 c'est mieux, si on a plus de windows c'est que windows c'est mieux ?
Pour Mozilla, si c'est en C++ c'est qu'ils se sont basé au départ sur du code de Netscape qui était en C++.
Pour le reste, je me demande vraiment qui manque d'objectivité...
-1 (débat de sourd entre un "connard susceptible borné qui fait chier" (d'après la tribune) et un employé de chez MS qui se contente de faire des éloges infondées sur sa boite)
[+] [^]Re: c++ su><or
Ce que tu comprends pas c'est que :
- L'industrie a INTERET a utiliser le langage le plus facile a maintenir, qui est le plus rapide pour developper.
- L'industrie faisait du C avant, et elle est passee au C++, c'est pas comme si ils ne connaissaient pas le C, ils ne faisaient que ca, et ils ont change car ils ont trouve que C++ repondait mieux aux besoins.
[+] [^]Re: c++ su><or
Windows est un OS au top niveau,
Access est une DB au top niveau,
Outlook est un mail server au top niveau,
SafeSource est un dev tool au top niveau,
et moi je suis la reine d'Angleterre ! Au top niveau !
Au caniveau ton FUD !
[+] [^]Re: c++ su><or
Windows est un OS au top niveau,
Access est une DB au top niveau,
Outlook est un mail server au top niveau
Windows est effectivement un OS au top niveau
Access, remplaces le par SQL Server qui detient un certain nombre de records, ca ira mieux
Outlook c'est pas un mail server mais un client
SafeSource c'est pas top a ce qu'il parait.
Mon FUD, tu peux te le foutre au c*l, mais ca je crois que tu le sais deja. Si t'as rien de plus interessant et argumente a dire que 'il FUD', reste dans ton coin ca rendra la discussion bien moins chiante.
[+] [^]Re: c++ su><or
> Windows est effectivement un OS au top niveau
dis, je peux l'encadrer ? ou au moins le rajouter parmi les fortunes... s'il te plait...
mwarf qu'est-ce qu'on se marre :)
-1
[^]Re: c++ su><or
Si, ça fait avec des #define, c'est pas joli joli, mais ça revient exactement au même que les templates, c'est le même niveau de saleté (du code dupliqué lors de la compilation)
Arrete c'est deguelasse et difficilement maintenable les #define. Pourquoi pas mettre une couche de m4 au dessus ? Exemple:
#define MAX(x,y) if (x < y) \\ x; \\ else y;
et ensuite dans le code
x = max(i++, j)
et boom i est incremente deux fois ou une fois c'est selon !
Au niveau des "templates code bloat" et des avantages des templates pour les performances je te conseille la lecture de l'excellent article:
http://osl.iu.edu/~tveldhui/papers/techniques/(...)
[^]Re: c++ su><or
x = max(i++, j)
Moi le mec qui me pond un code comme ca, je le jette tout de suite... que max soit issu d'un #define ou pas...
Ca fait trop mal au cul d'écrire deux lignes ??
Ah ben ouais, c'est bien plus mieux de montrer qu'on est un w4rl0rD qu'on déchire tout à écrire du code condensé...
Alors je suis plutot d'accord avec toi : Arrete c'est deguelasse et difficilement maintenable...
Bon je sais, t'a pris un exemple volontairement farfelu, mais c'etait juste pour poser ma gueulante sur les gens qui codent comme des gros sales, en C comme en C++.
« La clé d'une langue commune, perdue dans la Tour de Babel, peut être seulement construite par l'usage de l'Espéranto. » Jules Verne.
[+] [^]Re: c++ su><or
Si, ça fait avec des #define
Montre-moi comment tu fais de la spécialisation de templates avec des #define, par exemple.
[^]Re: c++ su><or
En C++, ta fonction elle se trouve une fois par fichier cpp et par type de données manipulé.
Le linker ne garde évidemment qu'un exemplaire de la fonction pour chaque type, c'est à dire pas tant que ça (tu n'appliques pas un sort<> sur des centaines de types différents non plus), et vu les capacités des machines actuelles, c'est négligeable.
polution du cache
Ça c'est un vieux mythe dont l'origine semble être l'inlining à outrance dans des templates mal écrit. Les templates ne posent pas de problèmes de perf à l'execution, c'est même le contraire : il n'y a qu'avec des templates que tu aura les meilleures perfs, justement parce que tu peux génèrer le code optimal pour ton cas. Ça n'est pas un hasard si Blitz++, une lib de calcul scientifique pour C++ dont les perfs également ou dépassent le code équivalenet en Fortran, est entièrement à base de templates.
de la mémoire, du disque dur
Tu as regardé les prix de ces choses-là dernièrement ? Ça ne coute plus rien. Ça n'est pas avec du code que tu vas bouffer ta mémoire, c'est avec les données qu'il traite. Avoir une fonction instanciée même une centaine de fois n'aura aucune différence.
temps de compilation affreusement longs, nécessité de recompiler toutes les application si un bugfix ou une mise à jour est appliqué dans la lib
Ça c'est hélas vrai.
Sans compter que la méthode C à base de pointeurs de fonction permet de faire des choses qui ne sont pas réalisables avec la méthode C++
C'est bien sur totalement faux. C'est même l'inverse, les templates t'affranchissent de la contrainte d'avoir une interface commune. Quand std::sort<> est instanciée sur un tableau d'int, derrière tu te retrouves avec l'operateur [] pour acceder directement au tableau, au lieu d'appels à des fonctions pseudo-virtuelles. Et si tu veux avoir une hierarchie globale, rien ne t'empèche de la faire.
Et bien sur, avec les templates tu restes type-safe et tu n'as pas besoin de caster dans tous les sens.
Ceci dit, le style tout objet (Ruby, Java) marche aussi très bien, l'expérience prouve qu'on développe plus vite avec, et l'absence de vérification de type n'est pas un si gros problème. Restent les perfs, ou C++ reste imbattable.
[^]Re: c++ su><or
Oui, via un conception à la java les fonctions n'apparaitraient
qu'une fois. L'aventage des templates c'est un code optimisé en
fonction du type/objet utilisé.
[^]Re: c++ su><or
Vas y fait voir le code avec la Glib apres on compare les avantages et les inconvenients sur cet example. J'ai un assez mauvais souvenir de la glib. Pour moi ca ressemblait a un sac de macros C, mais je ne demande qu'a etre convaincu..
ps: ca utilise intensivement les templates son exemple.
[^]Re: c++ su><or
mouaf... kael expert ès-programmation... retourne jouer à l'admin NT.... :-)