- la standardisation du C++
- les évolutions potentielles du C++ : bibliothèques standards, ramasse-miettes...
- la position de C++ par rapport à Java et C#
Aller plus loin
- Interview (35 clics)
Interview de Bjarne Stroustrup
11
juin
2002
Dans cette interview pour Développeur Référence, l'inventeur du C++ évoque :
- la standardisation du C++
- les évolutions potentielles du C++ : bibliothèques standards, ramasse-miettes...
- la position de C++ par rapport à Java et C#
- la standardisation du C++
- les évolutions potentielles du C++ : bibliothèques standards, ramasse-miettes...
- la position de C++ par rapport à Java et C#
# c++ su><or
Posté par kael . Évalué à -10.
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
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à -10.
.............
Non, je marcherai pas dedans !
[^] # Re: c++ su><or
Posté par Yann Droneaud (site web personnel) . Évalué à -10.
Tu me range ce c++ de merde. Tout le monde sais
que c'est pourri.
[^] # Re: c++ su><or
Posté par homoanonymus . Évalué à -7.
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
Posté par Blackknight (site web personnel, Mastodon) . Évalué à -10.
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
Posté par C2RIK . Évalué à 10.
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....
Posté par Alberto . Évalué à 10.
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....
Posté par kangs . Évalué à 2.
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....
Posté par Alberto . Évalué à 5.
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....
Posté par Nicolas Roard (site web personnel) . Évalué à 10.
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
Posté par martinc . Évalué à 10.
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
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 10.
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 ?
[^] # Re: Ca trolle déja sec dans l'interview
Posté par Yann Droneaud (site web personnel) . Évalué à -10.
apprecier le C++
[^] # Re: c++ su><or
Posté par Anne Batteux . Évalué à -7.
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
Posté par Gaël Le Mignot . Évalué à 10.
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
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à -6.
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.
[^] # Re: c++ su><or
Posté par Gaël Le Mignot . Évalué à 10.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à 10.
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
Posté par TSelek . Évalué à 10.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
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...
Posté par TSelek . Évalué à 4.
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...
Posté par Guillaume Laurent (site web personnel) . Évalué à 10.
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...
Posté par #3588 . Évalué à 7.
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...
Posté par kangs . Évalué à 7.
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
Posté par shbrol . Évalué à 10.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à 7.
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
Posté par Moby-Dik . Évalué à 8.
[^] # Re: c++ su><or
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
[^] # Re: c++ su><or
Posté par Neryel . Évalué à 10.
OnOn est barré correctement,non ?
[-1etjesorsencourant]
[^] # Re: c++ su><or
Posté par Lucas . Évalué à 8.
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
Posté par Gwenole Beauchesne . Évalué à 10.
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
Posté par Moby-Dik . Évalué à 5.
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
Posté par Gaël Le Mignot . Évalué à 5.
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
Posté par Laurent Mouillart . Évalué à -10.
-1 car beaucoup mais beaucoup trop gros.
[^] # Re: c++ su><or
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Vas-y, fais voir le code.
[^] # Re: c++ su><or
Posté par C2RIK . Évalué à 6.
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
Posté par Gaël Le Mignot . Évalué à -6.
[^] # STL = Standard Template Library
Posté par C2RIK . Évalué à 10.
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
Posté par kangs . Évalué à 3.
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
Posté par Yann Droneaud (site web personnel) . Évalué à -2.
Enfin bon ...
[^] # Re: c++ su><or
Posté par Simon_N . Évalué à 10.
[^] # Re: c++ su><or
Posté par Crao . Évalué à -2.
[^] # Re: c++ su><or
Posté par Alberto . Évalué à 6.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à 6.
Ou alors tu as une notion très particulière de ce qui est "équivalent".
[^] # Re: c++ su><or
Posté par TSelek . Évalué à 8.
[^] # Re: c++ su><or
Posté par Moby-Dik . Évalué à 7.
[^] # Re: c++ su><or
Posté par TSelek . Évalué à 0.
[^] # Re: c++ su><or
Posté par Emmanuel Blindauer (site web personnel) . Évalué à -1.
cf qsort vs. sort
[^] # Re: c++ su><or
Posté par kangs . Évalué à 0.
[^] # Re: c++ su><or
Posté par Gaël Le Mignot . Évalué à 8.
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
Posté par Nicolas Roard (site web personnel) . Évalué à 4.
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
Posté par MagicNinja . Évalué à 1.
[^] # Re: c++ su><or
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
D'un point de vue purement langage c'est pas indispensable, mais c'est pratique (coopérations c++/objectiveC)
[^] # Re: c++ su><or
Posté par Yann Droneaud (site web personnel) . Évalué à 5.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à -2.
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
Posté par Fabimaru (site web personnel) . Évalué à 10.
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...
[^] # Re: c++ su><or
Posté par Yann Droneaud (site web personnel) . Évalué à 2.
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
Posté par Alberto . Évalué à 8.
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
Posté par Fabimaru (site web personnel) . Évalué à 2.
[^] # Re: c++ su><or
Posté par pasBill pasGates . Évalué à 2.
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
Posté par Gaël Le Mignot . Évalué à -1.
[^] # Re: c++ su><or
Posté par pasBill pasGates . Évalué à 7.
- 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
Posté par Gaël Le Mignot . Évalué à -2.
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
Posté par pasBill pasGates . Évalué à 5.
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
Posté par Gaël Le Mignot . Évalué à 1.
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
Posté par Simon_N . Évalué à 2.
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
Posté par Gaël Le Mignot . Évalué à -2.
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
Posté par pasBill pasGates . Évalué à 1.
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
Posté par Gaël Le Mignot . Évalué à 2.
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
Posté par Simon_N . Évalué à 2.
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
Posté par Gaël Le Mignot . Évalué à -1.
-1
[^] # Re: c++ su><or
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Exemple ?
[^] # Re: c++ su><or
Posté par pasBill pasGates . Évalué à 5.
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
Posté par Gaël Le Mignot . Évalué à 1.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
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
Posté par Gaël Le Mignot . Évalué à -2.
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
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
La façon dont tu réponds aux mises en doute de tes compétences est également révélatrice.
[^] # Re: c++ su><or
Posté par Gaël Le Mignot . Évalué à 0.
décidément... ça devient n'importe quoi ici :(
[^] # Re: c++ su><or
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
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
Posté par pasBill pasGates . Évalué à 3.
- 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
Posté par Gaël Le Mignot . Évalué à 3.
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
Posté par pasBill pasGates . Évalué à 0.
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
Posté par Anonyme . Évalué à 1.
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
Posté par pasBill pasGates . Évalué à -1.
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
Posté par Gaël Le Mignot . Évalué à -2.
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
Posté par pasBill pasGates . Évalué à -2.
- 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
Posté par TSelek . Évalué à -2.
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
Posté par pasBill pasGates . Évalué à -4.
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
Posté par Gaël Le Mignot . Évalué à -1.
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
Posté par Alberto . Évalué à 5.
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
Posté par icyfemur . Évalué à 3.
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++.
[^] # Re: c++ su><or
Posté par Guillaume Laurent (site web personnel) . Évalué à -1.
Montre-moi comment tu fais de la spécialisation de templates avec des #define, par exemple.
[^] # Re: c++ su><or
Posté par Guillaume Laurent (site web personnel) . Évalué à 10.
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
Posté par kangs . Évalué à 2.
qu'une fois. L'aventage des templates c'est un code optimisé en
fonction du type/objet utilisé.
[^] # Re: c++ su><or
Posté par Alberto . Évalué à 4.
ps: ca utilise intensivement les templates son exemple.
[^] # Re: c++ su><or
Posté par Guillaume Lefevre . Évalué à 2.
# POA
Posté par Benjamin Michotte . Évalué à 10.
[^] # Re: POA
Posté par hugo . Évalué à 10.
Tu ajoutes de fonctions au compilateur Java standard pour accepter un nouveau type de structure, les aspects. Un aspect est construit très similairement à une classe.
L'autre point important est, dans le corps de ces aspects, du définis des points dans ton code. Ce peut être l'entrée dans une méthode d'une classe, les sorties de toutes les méthodes publiques d'une classe, la sortie sur exception de toutes les fonctions get*(String) dans un paquet... Bref, c'est très puissant pour définir des points dans ton code.
Ensuite, quand tu as défini ces points, tu définis des "méthodes" dans ton aspect qui vont se déclencher à ces points précis. Note bien que tu peux configurer tes points pour avoir accès au contexte d'appel de la méthode (la valeur d'une String par exemple, et suivant cette valeur, tu fais des choses différentes dans ta méthode d'aspect).
C'est en fait assez puissant, car toutes les fonctions remplies en plusieurs endroits du code peuvent être regroupées en un seul endroit, comme le logging par exemple. Au lieu d'appeler Logger.log(qqch) dans le code de ma méthode de classe, je ne touche pas à mon code, mais je crée un aspect qui va logger la réussite ou l'exception qui a eu lieu dans ma méthode. Et il est aussi facile de virer tous les logs en un seul endroit.
C'est un exemple de l'utilisation des aspects, si vous connaissez un peu Java, le site d'AspectJ est vraiment bon pour la doc (en anglais bien sûr ;-)
A+ Hugo
# c'est quoi cette merde ?
Posté par Dugland Bob . Évalué à -10.
Ca sert à rien cette news !
[^] # Re: c'est quoi cette merde ?
Posté par TSelek . Évalué à -3.
Il est pas beau le C++ nouveau avec un GC customisé à la jacky ?
Bon ben il est vraiment trop vieux ce troll, ça me fait de la peine, il va falloir l'achever ?
[^] # Re: c'est quoi cette merde ?
Posté par Dugland Bob . Évalué à -4.
Je reviens à l'instant de la lecture d'un ouvrage sur GTK, j'ai envie de vomir, c'est du pointeur dans tous les axes, du pointeur vers l'instance de la classe parente etc. et de la macro.
Les mecs n'ont _rien_ compris à la théorie des langages de programmation ! Un langage est là pour automatiser des taches répétitives, les langages objets sont compris dedans, créer des structures de données qui ressenblent à de l'objet dans un langage qui ne l'est pas relève du crétinisme (ou de l'opportunisme étant donné la mode de l'objet) alors qu'une application écrite en langage objet pourra souvent ne pas avoir une tronche objet une fois en mémoire.
Même si je ne suis pas encore un caïd du domaine, j'ai au moins compris la différence entre le niveau langage et le niveau run-time.
Franchement, je me détourne de plus en plus du libre, dégoûté par cette atmosphère de branlage de nouilles .
Il devient de plus en plus clair que l'open-source n'a rien à voir avec la qualité.
Je préfèrerais utiliser une application closed-source écrite pas Robert C. Martin que xinetd ou wu-ftpd par ex.
[^] # Excellent ! C'est un vrai meta-troll ! Regardez ça les jeunes !
Posté par TSelek . Évalué à 10.
[^] # Re: Excellent ! C'est un vrai meta-troll ! Regardez ça les jeunes !
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: Excellent ! C'est un vrai meta-troll ! Regardez ça les jeunes !
Posté par Moby-Dik . Évalué à -4.
[^] # Re: c'est quoi cette merde ?
Posté par Yann Droneaud (site web personnel) . Évalué à 7.
C'est clair que tout le monde ne comprend de la meme facon la programmation objet, mais de la a critiquer l'open source, je vois pas le rapport.
Enfin bon, tout le monde peut exprimer son avis.
[^] # Re: c'est quoi cette merde ?
Posté par Dugland Bob . Évalué à 2.
Je ne critique pas l'O-S mais je préviens que ce n'est pas un gage de qualité, et que l'O-S ne semble pas augmenter la qualité des applications.
[^] # Re: c'est quoi cette merde ?
Posté par Benjamin . Évalué à 10.
M'enfin, c'est vrai que c'est tres la mode ces temps-ci de parler du fait que telle nouvelle technologie de décideur pressé est developpée selon les toutes dernieres méthodes de devel/conception à la mode plutot que de montrer une bouse finale qui rame et qui coute cher
En pratique, je me fous completement de savoir que Linux est codé en C et Win95 en C++, tout ce que je veux, c'est utiliser un truc stable et bien.
[je critique absolument pas tel où tel langage/méthode de devel, juste la débilité du post "anti-opensource"]
[^] # Re: c'est quoi cette merde ?
Posté par Romuald Delavergne . Évalué à -3.
A toi de choisir.
[^] # Re: c'est quoi cette merde ?
Posté par Dugland Bob . Évalué à -4.
wu-ftpd
xinetd
bind
php
wmcoincoin
le module eci
le noyau (les 100Mo dans /usr/src/linux)
...
Mais je ne remets pas en cause le libre, juste le fait de dire open-source => qualité, c'est faux.
La qualité est indépendante de l'aspect open-source.
D'autre part j'ai pas parlé de libre (ou alors par erreur) mais uniquement d'open-sorce (simplement un truc dont tu peux voir les sources comme Windows dans une certaine mesure, QNX, les logiciels libres etc.).
[^] # Re: c'est quoi cette merde ?
Posté par Gaël Le Mignot . Évalué à 2.
Maintenant, si tu ne penses qu'à la qualité du soft et pas du tout aux aspects éthiques qui sont soulevés, c'est AMHA que tu n'as rien compris à la raison d'être du logiciel libre.
[^] # Re: c'est quoi cette merde ?
Posté par Dugland Bob . Évalué à -5.
Même un éditeur de texte tout con s'il chie au moment de la sauvegarde de 1 caractère ça pourrait faire des morts.
Je ne m'intéresse pas que à ça mais je m'y intéresse beaucoup d'où mon intérêt pour les "méthodes de production" du logiciel (langages, compilos, environnements etc.).
Si personne n'a la volonté de nettoyer la crasse dans laquelle le secteur de l'informatique se situe, on va dans le mur. Le "logiciel dont on peut voir le code source" aurait pû être la voix mais non, on a autant de merde dans ce secteur (qui comprend pas mal de libre en plus) que dans les trucs fermés. J'en viens presque à adhérer avec le tissu de conneries de MS : tant que tout le monde produira de la merde, autant la cacher ça limite la découverte des failles de sécrité. Quand les informaticiens se pencherons massivement sur les outils, les langages, les environnements etc. peut-être qu'on sera prêt à faire de la qualité.
Mais pour l'instant, y'a toujours les P4 qui bootent en 16 bits et un bloatware de 100Mo de C dans /usr/src/linux qui est prêt à te pêter à la tronche à chaque démarrage.
Maintenant si j'ai utilisé le mot open-source c'est parceque j'ai pensé que c'était plus clair mais si je me suis planté parce que je ne sait que organisme a utilisé un terme simple pour en faire un truc vachement moins simple et qu'en plus j'était pas au courant désolé.
Donc ce que j'ai dit avant c'était valable pour "les machins dont on peut lire le code source" ça va ? c'est pas déposé par un consortium de sauveurs du monde ça ? les-machins-dont-on-peut-lire-le-code-source.org n'a pas l'air déposé donc j'espère que je suis pas fait avoir et que ça veut pas dire un truc plus compliqué dont je me fous.
[^] # Re: c'est quoi cette merde ?
Posté par PLuG . Évalué à 2.
un bloatware de 100Mo de C dans /usr/src/linux
On attends tous avec impatience ta version C++ qui ne tiendra que 10Mo evidement.
En particulier, je suis curieux de voir comment tu va t'y prendre pour optimiser le biniou mieux que le bloatware actuel. Sur les passages critiques (critical path, huh ?), ils en sont a pondre le code C qui va bien pour que la version de gcc utilisée produise le bon code. [ce qui est mal (tm) je le concède volontier].
Dans ta version C++ avec moult templates et autres heritages, je suis impatient de voir comment tu pourrais optimiser mieux ...
Le C++ a bien des avantages, mais il est des domaines ou le C est suffisant. J'ai relu le code du vfs ce WE [<ma_vie>je voulais modifier le systeme dnotify</ma_vie>], le code est limpide meme s'il utilise des pointeurs de fonction a chaque fois que necessaire.
[^] # A quand un OS "INBUGABLE" ?
Posté par darkleon (site web personnel) . Évalué à 5.
Avec les outils actuels, on ne peut pas prouver que le code est "bug-free" et avec les évolutions constanes (sources de nouveaux bugs), ça peut pêter à la figure.
C'est vrai que si cet OS parfait existait, l'industrie du logiciel aurait du soucis à se faire :-)
<disgression // avec le sujet>
L'argument avancé est la "performance", vraiment, on s'en fout complètement, c'est parce que les logiciels sont de plus en plus gourmands qu'on est passé d'un 386@16mhz/4Mo/HD 40mo en 1990 a un PIV@2.2ghz/256mo/HD 40go.
Et en 1990, on pouvait déjà faire de la bureautique wysiwig sous win3.1 ou sur amiga ou sur mac, sur unix, c'était du Latex(d'ailleurs le seul soft qui n'a pas de bug depuis plusieurs années et c'est bizarre, ça a été codé par un mathématicien et non pas par un haxor), X11 avec 4mo et un logiciel bureautique c'était un peu de la SF.
Fondamentalement, est-ce que WORD XP fait beaucoup plus de choses que WORD 2.0 (je prend cet exemple parce que c'est grosso-modo le même soft qui a évolué sur 10 ans).
est ce que word 2.0 ne suffit pas pour faire 99% des documents actuellements produits dans le monde. Est-ce que l'ergonomie de ce logiciel a si fondamentallement changée qu'on écrit un document 10 fois plus rapidement ? La réponse est NON, il est seulement plus lent, a surement plus de bugs même si les anciens sont corrigés, il faut une machine beaucoup plus puissante qui consomme plus de courant et qui est moins fiable parce qu'elle chauffe beaucoup plus.
Finallement, c'est quoi le "PLUS", ben c'est plus joli, c'est tout, on va me dire qu'il y a plus de fonctions, mais elles ne sont pas utilisés.
Et ne commencez pas à lancer un troll MSOffice/OpenOffice, OpenOffice à besoin de X11 sur un bureau moderne pour fonctionner il est peut être meilleur techniquement, mais il lui faut aussi au moins 64mo de RAM pour être utilisable.
</disgression // avec le sujet>
Bref il n'y aucun effort qui est fait pour "améliorer les performances" et ce n'est pas le choix JAVA/C# ou C++ ou C qui infléchieront la tendance (ponctuellement, on ira 2 fois plus vite avec un code C qu'en JAVA, bah l'industrie informatique stagnera sur 18 mois :-)
Enfin non on ne s'en fout pas de la performance, mais si je dois choisir entre une machine garantie sans bugs 10 fois plus lente et une techno actuelle, j'ai vite fais mon choix.
Les premiers systémes unix devaient tourner avec 128ko de ram environ (c'est l'ordre de grandeur). Et c'est sur ces machines que les premiers compilos C ont été développés.
Maintenant, on considére que Linux est utilisable avec 8mo en mode console (128mo avec X).
Maintenant qu'on est 1000 fois plus rapide et 1000 fois plus de mémoire, on pourrait peut être penser à developper de nouveaux langages ou de nouveaux concepts de programmation.
Le soft n'a pas évolué en 30 ans (a part la notion d'objet, mais l'algorithmie ça vient des années 70).
On va se retrouver avec des architectures qui héritent des erreurs du passées "parce que c'est comme ça", comme on a la semaine de 7 jours et des journée de 24 heures, on va peut être se payer le format doc pendant des millénaires, parce qu'on ne va pas toucher l'existant.
Qu'en entreprise, les gars soient traditionalistes, ça ne me choque pas, mais à la fac ça n'évolue pas non plus.
ça me fait penser aux articles sur la reconnaissance vocale qui ressortent tous les 2 ans en disant "ça y est, cette fois ça marche".
Mais pratiquement tous les algo ont été développés entre 1960 et 1980, on ne fait que les affiner, il n'y a pas de révolution.
Pour moi, le C++ quelque soit ses qualitées ou ses défauts va se retrouver dans des niches, balayé au fur et à mesure par le C# et le Java, parce ne pas gérer ses pointeurs, ça te fait gagner un max de temps, et pour les petits dév bas niveau, le C remplit trés bien son rôle de "macro-assembleur portable".
L'histoire aurait été largement changé si effectivement la STL était sortie avec le C++ en 1985, il y aurait eu une bascule beaucoup plus visible sur des dev C++, car ils auraient été beaucoup plus rapide et standard qu'en C.
Maintenant, il est beaucoup plus rapide de développer en JAVA/C#, et c'est le coût d'un développeur à la journée qui est plus important que le matériel, 3 jours de dev=1 machine, un projet de 50 personnes avec 6 jours de retard correspondent à 100 machines.
Donc même si il faut acheter un serveur à 100K euros au lieu de 50K euros pour combler le manque de performances du JAVA/C# sur le C++/C le client s'y retrouve rapidement sur les frais de développement.
[^] # Re: A quand un OS "INBUGABLE" ?
Posté par Toufou (site web personnel) . Évalué à 2.
Dans une optique SSII / Editeur sans doute, pas quand tu programmes en interne pour ta boite. Je ne peux en aucun cas dire à mon chef : "j'ai besoin de trucmuche v2.0 qui ne tourne que sur P4 pour développer plus vite, il va falloir changer les 3000 machines du site pour qu'elles puisse faire tourner les libs de ce que je développe.".
[^] # Re: A quand un OS "INBUGABLE" ?
Posté par darkleon (site web personnel) . Évalué à 2.
Un article démontrait que si tu devais lancer un calcul qui devait prendre plus de 26 mois, c'était plus rentable d'attendre la génération des machines 2 fois plus puissantes et faire un calcul de 8 mois pour arriver au même résultat.
En gros si tu dois mettre 2 fois plus de temps pour coder une application optimisée, il vaut mieux l'écrire de manière moins optimisée (à condition que les temps de réactions soient raisonnables) et propre. Et Si en plus elle est faite pour durer, même si les 3000 postes sont à 500mhz pour le moment, et bien dans 5 ans ils seront à 5ghz.
Donc l'optimisation vaut le coup pour :
-une application de calcul pur (ex modélisation, traitements temps réels, etc).
-une application quick&dirty jettable (ex jeux).
Bon maintenant, si tu es un dieu en C++/C que tu codes du premier coup sans avoir de fuites de mémoires, autant prendre le langage le plus rapide. ça vaut surtout le coup pour les applications graphiques ou il y a beaucoup d'interactivité et peu de répétitions.
Pour tout ce qui est opérations répétitives sans interactivité (filtrage constant d'un flux par ex) JAVA devient trés performant, parce que la JIT va affinner le code assembleur généré, et au bout de 10 passes tu obtiens un code presque aussi performant que du C.
C'est comme tout, il faut choisir l'outils le plus adapté à ta situation.
Reste que pour moi C++ va vers des niches ou la performance prime tout en ayant un peu plus de rigueur dans le codage que le C qui est un "assembleur évolué".
[^] # Re: A quand un OS "INBUGABLE" ?
Posté par Toufou (site web personnel) . Évalué à 3.
Eh bien, ici c'est plutôt du Delphi, mais ça ne change pas grand chose de toutes manières: les libs et mécanismes utilisés sont gourmands. Le facteur limitant chez moi n'est certainement pas le CPU (sauf peut-être sur les serveurs, et encore) mais la mémoire. Dans ce contexte, Java est totalement inimaginable.
même si les 3000 postes sont à 500mhz pour le moment
Snif, si seulement c'était vrai ! La moyenne dans ma boite (centre de recherche pour l'état), ça doit être le celeron 300/400 avec 64 Mo, parfois 128Mo. Pour ma part, je suis un gros privilégié avec mon celeron 700 à 128Mo. Allez, soyez sympa, dites moi que c'est pareil chez vous, je me sentirai moins seul :)
il faut choisir l'outils le plus adapté à ta situation.
Oui je pense que c'est le fin mot de l'histoire. De toutes façons, rares doivent être les "grouillots" qui choississent l'environnement de developpement eux-même sans subir les choix/lubies de leurs décideurs pressés et l'historique de la boite.
[^] # Re: A quand un OS "INBUGABLE" ?
Posté par Dugland Bob . Évalué à 3.
Par-contre il bouffe au démarrage (surtout si t'es en JIT).
Tout ce que vous faites en désallocation explicite, le GC peut le faire (en général plus vite que vous) mais lui il sait faire des trucs que vous pouvez pas faire sans utiliser un ref_counter et un détecteur de cycles.
L'avantage du GC c'est qu'il n'utilise que l'infrastructure d'un détecteur de cycles (parcours du graphe et marquage) et pas une série de compteurs.
D'autre part tu peux régler le ratio bouffage de temps/bouffage de mémoire et jouer sur la durée de vie de la mémoire.
Même en temps réel, on commence à pourvoir controler le temps de réponse (avec des systèmes spéciaux).
Il faut vraiment étudier ls GC avant de pouvoir dire qu'on en a pas besoin.
[^] # Re: A quand un OS "INBUGABLE" ?
Posté par darkleon (site web personnel) . Évalué à 2.
Non il faut arrêter de rigoler, Java bouffe énormement de mémoire au démarrage, même si le GC est plus efficace que la gestion à la main (ce que je crois sans problème, cf fuites de mémoires) il n'en reste pas moins qu'en moyenne, une JIT, c'est 12~14mo de pris, plus les 2 ou 3 initialisations de bases, et si tu commences à mettre pleins de gadgets swing, tu arrive trés facile vers les 40mo. Avec 64mo de RAM ça un peu trop juste.
Si en plus tu lances 3 applis jave, tu as 3 fois 12~14mo qui sont pris pour rien, il faudra attendre le jdk 1.5 ou 1.6 pour lancer plusieurs applis avec une JVM.
Si tu commences à faire une calculette .class~100ko, une appli de calcul .class~800ko, et bien au démarrage c'est quand même ~29mo au lieu de ~1mo qui seront utilisés.
Tu ne peux pas t'amuser à developper une floppée d'utilitaires en JAVA.
C'est vrai que je pensais plutôt à des postes "mono-application" spécifique (un serveur quoi :-).
Je me vois mal avec un ordi ou tous mes utilitaires seraient en JAVA
C'est un peu la faute de sun, JAVA est bien conçu, mais il n'ont jamais vraiment fait d'effort pour optimiser leur JVM (cf JVM microsoft qui est 2 fois plus rapide en applet que la jdk 1.4 sur des démos java du groupe equinox http://equinox.planet-d.net/java/(...) )
Donc je suis d'accord que JAVA est construit sur des bases solides, j'aime bien le java, mais la JVM c'est pas ça du tout.
[^] # Re: A quand un OS "INBUGABLE" ?
Posté par Dugland Bob . Évalué à 1.
Le but est simple : une seule instance en mémoire des infrastructures.
Smalltalk c'est planté sur cet objectif, peut-être MS arrivera à quelquechose.
Il semblerait hélas que certains n'aient pas compris ce problème et préfèrent fustiger Mono que d'essayer (ben oui, c'est pas gangé) de passer la seconde dans le secteur de l'informatique.
Ceci à plusieurs avantages : ça leur permet de vivre sur leurs acquis (le C et son environnement pile d'appels, représentation mémoire etc.) mais surtout de continuer à faire partie d'une élite qui serait sinon vite balayée par une génération formée plus tôt à une informatique plus moderne.
Il reste un pb MS n'est pas précisément connue pour ça capacité à faire progresser l'informatique. Le fait de mettre un PC sur chaque bureau sans former les utilisateur à la "science du traitement automatisé" ou à la "science de l'information" peut difficilement être qualifié de progrès. C'est pas en noyant un domaine de boulets qu'on fait progresser une science. Bien au contraire.
Donc le CLR .net est incontestablement une bonne idée mais il ne faut pas en faire n'importe quoi et c'est pas en faisant l'autruche que l'on l'aprivoisera.
[^] # Re: c'est quoi cette merde ?
Posté par Gaël Le Mignot . Évalué à -1.
oulàlà, ton troll, il est vraiment pas joli non plus.
[-1]
# OCM 2002
Posté par pifou . Évalué à 10.
Sa présentation était relativement technique et il semblait vouloir dire à la communauté objet présente que le C++ était vraiment génial et qu'il permettait d'écrire du vrai code objet comme en Java (par exemple) mais avec une plus grande souplesse (redéfinition de opérateurs, templates ...).
Pour ma part, j'ai été un peu déçu de sa prestation ... je n'ai rien appris de plus que pendant des cours de C++ (notion objet: héritage multiples, templates ...).
<ma vie>
Pour ma part je préfére toujours utiliser un vrai langage objet (Eiffel, SmallTalk, Java?) plutôt que du C++. Le problème(l'avantage???) de C++ pour moi, c'est qu'il faut être très strict dans sa façon de développer si on ne veut pas se retrouver avec un programme écrit moitié objet/moitié procédural (ou avec des segfault à chaque coin de méthode :o).
Quand tu écris un programme en SmallTalk ou Eiffel(avec les notions de contrats) (voire Java) tu es obligé d'écrire du code réellement Objet.
Le problème de Eiffel et surtout SmallTalk, c'est que très peu de personnes les utilisent. Heureusement il nous reste encore Python et Ruby pour les petites(et moyennes) applis.
Je pense toute de même que le C++ garde un grand intêret pour les applications scientifiques complexes et que le C est certainement le meilleur choix pour le developpement d'un noyau.
</ma vie>
J'espère ne pas trop nourrir le troll (si c'est le cas je suis réellement désolé) :o)
[^] # Re: OCM 2002
Posté par lorill (site web personnel) . Évalué à 3.
Un peu de serieux... Tu trouves vraiment que Python et Ruby sont très utilisés ? Je n'ai rien à leur reprocher, sinon le peu de developpeurs, justement.
[^] # Re: OCM 2002
Posté par pifou . Évalué à 3.
Pour python, il y a quand même qq appli qui existe (Sketch et pyCoinCoin par exemple).
De plus python est très pratique pour faire du prototypage (c'est mon cas pour un projet de mise en place de contrats/classes-autotestable (à rapprocher à junit)) avant de faire une version stable en Java (ou autres).
Enfin je ne voulais pas vraiment dire que Python et Ruby était super utilisés mais juste que tu pouvais toujours programmer une appli dans ces langages et qu'une personne voulant l'utiliser y arriverait relativement facilement (comme pour Perl). Ce n'est pas vraiment le cas avec Smalltalk, je ne suis pas sûre que grand monde est un compilateur(interpréteur) ST sur sa machine.
-1 car je me suis mal exprimé dans mon premier commentaire.
[^] # Re: OCM 2002
Posté par Laurent Saint-Michel . Évalué à 5.
Un peu de serieux... Tu trouves vraiment que Python et Ruby sont très utilisés ? Je n'ai rien à leur reprocher, sinon le peu de developpeurs, justement.
c'est pas tout à fait vrai car la communauté se dévellope avec par exemple ILM (la boite effet spéciaux de Lucas) :
"`The compositor plugins are in Python'', he notes. ``We're a big Python shop...and MEL.'' MEL is the Maya scripting language. "
source : http://www.linuxjournal.com/article.php?sid=6011(...)
A+
[^] # Re: OCM 2002
Posté par Guillaume Laurent (site web personnel) . Évalué à 10.
Et en quoi est-ce que ça garantit que ton code soit meilleur ?
Le paradigme objet n'est pas universel. Il y a des choses qui se représentent très bien en procédural de base, et les représenter en Objet va juste compliquer le code inutilement.
[^] # Re: OCM 2002
Posté par pifou . Évalué à 9.
Le paradigme objet permet, comme l'a mis en évidence B. Meyer, de représenter d'une façon simple des problèmes mettant en actions un nombre d'acteurs importants (exemple de la modélisation d'un champ de bataille avec des chars).
De plus, des langages comme Eiffel (ou Java avec des surcouches comme iContract) mettent en place la notion de contrats(pré/post condition sur les méthodes et invariants de classe) qui permet de spécifier le protocole d'utilisation d'une classe plus formellement que sa signature seule et ainsi augmente la confiance que l'on peut avoir sur du code fournit par une tierce personne (principe de réutilisation).
De plus, il existe nombre de méthodes (classes-autitestable, génération de mutants ...) de développement permettant encore d'augmenter la confiance que l'on peut avoir dans du code objet. Mais cela est une autre histoire qui n'a pas grand chose à voir avec cette news.
[^] # Re: OCM 2002
Posté par Guillaume Laurent (site web personnel) . Évalué à 6.
En théorie oui. En pratique, c'est le genre de truc que les programmeurs detestent parce que c'est extrèmement chiant à maintenir. Trop lourd, trop contraignant. Chaque fois que tu changes le code d'une méthode, il faut changer le contrat aussi.
A part pour du code "mission critical", tu ne vas jamais réussir à imposer ça à une équipe de développeurs.
[^] # Re: OCM 2002
Posté par pifou . Évalué à 10.
Normalement si tes contrats (preconditions et postconditions) sont bien écrit, ils ne doivent pas être modifié quand le code change, sauf si tu t'es planté dans tes specifs (en effet, le mieux est d'écrire tes contrats à partir des spécif (diagrammes UML), et d'ensuite coder les méthodes). Je te l'accorde, c'est assez idéaliste comme point de vue.
Exemple: tu écrit une classe Set (tableau ne pouvant pas contenir de doublons, ex: (8,2,3,6)=>OK, (2,3,2,6)=>KO) avec une méthode add (pour ajouter un éléments), tu auras des contrats du type :
signature:
public void add (int member // élément à ajouter )
précondition:
@pre !has(member) implies size() < MAX_SIZE // Verification que tu peux encore ajouter un élément dans ton Set si l'élement passé en paramètre n'est pas déjà dedans
postcondition:
@post has(member) == true // l'élément que tu as ajouté est bien dans ton Set à la fin de ta méthode
@post has(member)@pre implies size() == size()@pre // Si l'élément était déjà dans ton Set alors la taille de celui-ci doit être le même à la fin de ta méthode
@post ! has(member)@pre implies size() == size()@pre + 1 // Si l'élément n'était pas dans ton Set alors celui-ci doit avoir un élément de plus à la fin de ta méthode.
has() et size() étant une méthode de la classe Set
Ca parrait assez lourd à mettre en place, mais ça permet de vraiment spécifier comment fonctionne ta classe, du coup tu fais moins de doc, et il y a moins d'ambiguité sur la façon de mettre le code en place. Un des avantages est que les postconditions peuvent servir d'oracle durant tes tests. De plus, il existe de bon bouquin d'initiation à la programmation contractuelle (par exemple :Design by Contract, by Example de Richard Mitchell and Jim McKim)
Etant moi même un flemmard de la programmation (j'aime pas mettre des commentaires et vérifier pendant trois plombes mon code), j'ai vite compris l'intéret de cette approche.
Je t'accorde qu'il n'est pas facile d'imposer une telle approche dans une équipe, mais c'est un choix de méthode de développement (comme par exemple pour l'eXtreme Programming). Il y a des avantages et des inconvénient.
J'essayerais de faire un condensé (ou d'en trouver un) sur cette approche si j'ai le temps.
-1 car c'est vraiment pas le sujet de la news
[^] # Re: OCM 2002
Posté par Guillaume Laurent (site web personnel) . Évalué à 3.
Donc, en pratique, tu sais qu'ils ne le seront pas
ils ne doivent pas être modifié quand le code change, sauf si tu t'es planté dans tes specifs
Et en pratique, les spécifs changent.
Je te l'accorde, c'est assez idéaliste comme point de vue.
Oh, si peu :-).
[^] # Re: OCM 2002
Posté par pifou . Évalué à 4.
Et en pratique, les spécifs changent.
Oui et non, en fait il faut rapprocher la programmation contractuelle à un cycle de maintenance (ou comme XProgramming) :
Tu fait tes specifs (contrats + tests) -> tu codes -> tu lances tes tests -> tu peux avoir des erreurs de violation de contrat (code faux ou contrat faux), dans ce cas tu modifie tes contrats/codes ou alors t'obtiens pas le résultat attendu (normalement détecté par une postcondition), donc tu modifie tes spécifs (donc tes contrats et ton code) et tu cycles jusqu'à avoir un niveau de confiance assez fort.
En gros ce sont des cycles très courts basés sur 3 points : Specification->Tests->Implémentation.
En plus tu peux générer des mutants (insertion d'erreur dans une classe) pour vérifier que tes contrats détectent bien les erreurs générées dans ces mutants.
[^] # Contexte....
Posté par Moby-Dik . Évalué à -2.
@pre !has(member) implies size() < MAX_SIZE // Verification que tu peux encore ajouter un élément dans ton Set si l'élement passé en paramètre n'est pas déjà dedans
Résumons en reprenant le contexte.... Le post original parle de l'interview du créateur de C++, un langage où une classe nommée std::vector permet de faire des tableaux de taille arbitraire. Il y a aussi une classe std::set permettant de faire des ensembles de taille arbitraire. Tout ça avec la librairie standard.
Et là, pour nous expliquer que son langage est tellement plus mieux, un zigue nous sort l'exemple roulé sous les aisselles d'un Set codé à la main et limité en taille par une constante figée.
Ben moi, je sais pas pourquoi, je trouve ça marrant .... ! ;))
[^] # Re: Contexte....
Posté par pifou . Évalué à -1.
Et là, pour nous expliquer que son langage est tellement plus mieux, un zigue nous sort l'exemple roulé sous les aisselles d'un Set codé à la main et limité en taille par une constante figée.
Pour ta gouverne la taille de la constante figée est en rapport avec la taille maximal que Java peut atteindre avec un int. A l'origine le Set en question était un Set d'entier donc logiquement tu ne peux pas avoir plus d'entier dans ton Set que ce que Java peut représenter, d'où la vérification que tu n'essayes pas d'ajouter un élément dans un Set complètement rempli.
D'autre part il est bon de se rappeler, même dans les langages haut niveau, que ton espace mémoire est limité, la constante même si elle a une valeur importante permet de spécifier une taille maximal pour ton Set.
Enfin, mieux vaut trop que pas assez. La notion de contrat permet l'incomplétude (t'es pas obligé de tout spécifer pour que ton programme tourne) mais il est toujours préférable de prévoir tous les cas possibles même si on les considère comme peu probable (dans le cas du Set d'entier, tu auras certainement saturé ta mémoire avant de l'avoir rempli entièrement :o).
Ca peut sembler un peu capilotracté comme approche, mais c'est pas sur 5 commentaires que je peux expliquer une telle notion.
-1 Car j'ai déjà écrit la moitié des commentaires de ce thread :o).
[^] # Vive Java et à mort l'oppression qui nous réprime
Posté par Moby-Dik . Évalué à 4.
Ouaip parce qu'après il y a des gens sensibles qui ont des maladies graves en tombant sur ce genre de choses. Faut pas déconner.
Moi, je trouve qu'on devrait dire aux programmeurs du noyau Linux que c'est que des brêles qu'ont rien compris au développement, regardez : ils mélangent de l'assembleur avec du C ! Un langage super bas niveau avec un langage moins bas niveau ! Alors que dans ma super école d'informatique où j'ai appris la vie en dix leçons (garanti satisfait ou remboursé), on m'a bien dit qu'il fallait pas mélanger et que si des gars ne suivaient pas les préceptes de la programmation bénie-oui-oui telle qu'enseignée par des mangeurs de quiche frustrés qui n'ont jamais pondu un bout de code inventif, alors je pouvais leur dire que c'était des abrutis et tout reprogrammer à leur place (pas pour de vrai non plus, faut pas exagérer, j'ai des tas de bouquins intéressants à lire sur la programmation objet). Alors quoi hein, vive Java et à mort les langages qui permettent de faire des choses. Amen.
Signé :
Un étudiant en informatique qui sait plein de choses vachement importantes.
[^] # Re: Vive Java et à mort l'oppression qui nous réprime
Posté par pifou . Évalué à 6.
Faut savoir ce que l'on fait, je n'ai jamais dit que c'était mal de mélanger du C et de l'assembleur, mais je trouve tout de même abérrant qu'une personne disant 'je programme en C++ pour faire du langage objet' puisse se dire 'mince, pour cette fonction c'est plus simple de coder en C' (alors que la plupart du temps, c'est juste parcequ'il à la flemme d'aller chercher une solution propre en Objet).
C'est, je pense, un peu ce que veux dire Bjarne Stroustrup, il est tout à fait possible d'écrire des programmes objets d'une qualité bien meilleur qu'en Java. Le problème du C++ c'est que, étant dérivé du C, il permet d'écrire du code pas du tout objet.
Enfin, je ne suis pas un fan de Java, je le trouve bien trop frilleux sur certain point (pourquoi avoir gardé un système de structure de contrôle procédural (if then else, while ...) ? pourquoi avoir des types primitif, et une classe mi objet/mi primitif (String) ? en fait la réponse est simple : Sun à préféré privilégié la performance et le faut pas perturber les personnes venant du procédural :o().
De même, je ne m'amuse pas à écrire mes scripts en Java :o), j'utilise (trop?) souvent Perl et quand j'ai le temps en Python (ou Ruby).
Pour conclure :
Il y plein de types de programmations (procédural, fonctionnel, objet ...)
Il y plein de langages dans chaque type de programmation (SmallTalk, Eiffel, C++, Java entre autre pour l'objet)
Il y plein de types d'applications différentes (kernel, office, applet ...)
Le tout est de trouver le meilleur langage pour programmer ton application selon ses besoins (vitesse d'execution, espace mémoire nécessaire, portabilité, qualité(ou plutôt confiance), vitesse de développement ...).
Il faut de tout pour faire un monde (libre) (comme nous l'a si bien appris le générique d'Arnold et Willy :o)
nb: Je suis aussi étudiant en informatique, et suis surtout pragmatique, je préfére de loin coder plutôt que lire 3 tonnes de bouquin. Par contre je suis plutôt orienté programmation haut niveau (j'aime pas ce terme, il y a une notion de supériorité par rapport au bas niveau que je ne trouve pas fondée), il n'empeche que je suis l'un des premiers à trouver génial(et à utiliser) ce que font les développeurs du Kernel Linux(je ne pourrais jamais faire ce qu'ils font)
[^] # Re: Vive Java et à mort l'oppression qui nous réprime
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
Qu'attendait tu à la place ?
pourquoi avoir des types primitif, et une classe mi objet/mi primitif (String) ?
Ca c'est clair que c'est assez pourri, conceptuellement, de ne pas avoir les types de base en objet.
D'un autre côté, c'est pragmatique :)
[^] # Re: OCM 2002
Posté par kangs . Évalué à 3.
>moi, c'est qu'il faut être très strict dans sa façon de développer si on ne veut pas se retrouver avec un programme écrit moitié objet/moitié procédural
>(ou avec des segfault à chaque coin de méthode :o).
L'inconvénient de la compatibilité avec le C, quand tu as surtout développé en procédural, tu as
du mal à passer à l'objet. Une fois les notions objets bien acquises je ne pense pas que tu ais
de problème pour faire du bon code.
De plus, perso, je ne pense pas que le C est meilleur que le C++ ou inversement,
mais que la programation procédurale me parait complètement obsolète par rapport
à ce qu'apporte l'objet.
Quand tu fais des bidouilles l'objet est chiant, et j'ai l'impression que
souvent si l'objet est critiqué c'est que l'on parle d'avantage de conception
notion qui echappe parfois à certains.
# Et si on parlait de design patterns ?
Posté par TSelek . Évalué à 7.
[^] # Re: Et si on parlait de design patterns ?
Posté par DiZ . Évalué à -2.
>clou.
OpenStep
http://gnustep.org/resources/OpenStepSpec/OpenStepSpec.html(...)
Et le jdk, c'est juste un framework OpenStep raté.
[^] # Re: Et si on parlait de design patterns ?
Posté par TSelek . Évalué à 3.
# C++ c'est trop de la ...
Posté par bozmvcqd . Évalué à -10.
Non sérieusement pourquoi ce faire chiez avec ce langage alors qu'il en existe d'autres tout aussi puissant et beaucoup moins chiant a utiliser.
Je pense en particulier a OCaml (http://caml.inria.fr(...))
[^] # Re: C++ c'est trop de la ...
Posté par djrom . Évalué à -10.
P.S Ceci est un test de post ! Ne cliquez pas sur "-" SVP !
[^] # Re: C++ c'est trop de la ...
Posté par homoanonymus . Évalué à -5.
J'ai profité de ton post pour tester le clic [-].
P.S Veuillez testez le clic [+] ici SVP !
[^] # Re: C++ c'est trop de la ...
Posté par Franck Guillaud . Évalué à 6.
Sans doute parce que le C++ est très utilisé dans l'industrie. Industrie au sens large : tu sais la vraie vie, dans une entreprise, où tu dois maintenir du code existant, où on ne te laisse pas le choix du langage sur un nouveau projet parce que des directeurs techniques en ont fait le choix à ta place.
C'est moche la vie ;-)
# C - -
Posté par Cook Captain . Évalué à 4.
- pour le bas niveau : kernel, drivers et qq applis specifiques => C
- pour le reste (90% AMHA) => Java
Depuis que je programme en Java (et plus en C++), je consacre beaucoup plus de temps à mes algos et à l'architecture de mes softs qu'a les debugger et ca, ca fait vraiment du bien.
[^] # Re: C - -
Posté par Neryel . Évalué à -4.
[^] # Re: C - -
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Ben non, C++ justement.
- pour le reste (90% AMHA) => Java
Sauf les applis desktop, genre traitement de texte, mailer, etc... Tu ne refera pas un équivalent de KDE en Java par exemple.
Ceci dit, je suis d'accord, Java est un bien meilleur langage que C++, et c'est bien dommage qu'il ne puisse pas le remplacer partout.
[^] # Re: C - -
Posté par Marc Quinton . Évalué à 2.
[^] # Re: C - -
Posté par Moby-Dik . Évalué à 3.
On peut la refaire pour les serveurs Web aussi, et puis les applis statistiques, les routeurs, l'imagerie 2D et 3D, le traitement vidéo.... Putain Java ça va torcher tout ça grave.
Et puis au final, même les JVM on les écrira en Java, parce qu'il faut bien que le système reste fluide :))
[^] # Re: C - -
Posté par Laurent Saint-Michel . Évalué à -2.
A ma grande surprise, dans ce cas particulier les programmes n'avaient pas un grand écart de duréée de traitement pour la même image. Il est vrai cependant que :
-la majorité du programme était du pur calcul matriciel
-le programme OO _était_ fortement optimisé
-je ne sais pas si le programme C était particulièrement optimisé lui.
-1 parce que pas sur des infos
A+
[^] # Oracle et Java
Posté par God . Évalué à 2.
Compare PostgreSQL (du pure C) et Oracle, et PostgreSQL sera bien plus rapide, seulement il supporte pas (encore) tout ce qui est clustering...
[^] # Re: Oracle et Java
Posté par Jean-Yves B. . Évalué à 4.
Sinon, moi, depuis que je code en Java mes applis sont automatiquement thread-safe, gèrent le partage mémoire comme jamais et tout ça sans rien coder ! Java c'est d'la balle (tm) ! J'ai le clustering gratuit avec !
[-1, je rale, je rale]
[^] # Re: Oracle et Java
Posté par pasBill pasGates . Évalué à 3.
Moi je veux bien te parier 1 million de $ que sur des bases de grosse taille Oracle eclate PostgreSQL en vitesse.
Oracle c'est pas fait pour gerer les recettes de cuisine de grand-mere ou la gestion de stock d'une petite PME de 4 employes, par contre quand il s'agit de gerer les bases de donnees d'une societe de 10'000 employees qui sont accedees/updatees/... journalierement, ton PostgreSQL fond comme un glacon au soleil pendant qu'Oracle continue sont petit bonhomme de chemin.
C'est toute la difference entre faire du 0 a 100 en 1.2s mais pas pouvoir faire du 100 pendant plus de 500m, ou faire du 0 a 100 en 1.4s mais faire du 100 pendant des kilometres.
[^] # Re: Oracle et Java
Posté par PLuG . Évalué à 1.
De plus, contrairement a ce qui a été écrit plus haut, cela m'etonnerai que le moteur sql d'oracle ait été ré-implementé en java.
Dans oracle, il y a maintenant des interfaces java, la possibilité de faire des procédures stockées en java, mais l'optimiseur interne et le moteur sql il sont certainement encore en C.
[^] # Re: Oracle et Java
Posté par God . Évalué à 3.
Pour ce qui est de la comparaison Oracle/PostgreSQL, c'est pas du facile ni du régulier mais bon, pas de problèmes (sauf mon compte en banque) : on prend deux machines identiques, une avec Oracle et une avec PostgreSQL, on fait les mêmes tests sur des trucs bien différents : requêtes simples/complexes, tables vides/remplies et on verra qui gagne !
Ce qui fait la force d'Oracle, c'est la possibilité, super bien exploité, de chainer et de parallèliser les bases sur plusieurs ordinateurs, point barre.
Alors une base assez conne avec assez d'utilisateurs supportables par une machine, PostgreSQL te grille Oracle, le reste c'est des idées reçues.
MySQL suffit pour la plupart des sites Web, c'est surtout parce que c'est pas critique, surtout de la lecture de données et pourtant c'est pas une vraie base relationnelle comme PostgreSQL et Oracle (sauf avec l'ajout de patch et autres bidouilles bientôt supportés de base)
Maintenant cite moi une utilisation d'Oracle critique : ou elle ne soit pas déployée sur plusieurs stations, ce qui manque cruellement à PostgreSQL (avec une intégration aisée avec tout le monde transactionnel distribué)
[^] # Re: Oracle et Java
Posté par PLuG . Évalué à 2.
Postule et gagne.
C'est assez complexe de comparer des bdd.
Le base mirorée en directe (oracle joue les redo log d'une base sur une autre distante pour etre pret a reprendre a chaud) c'est pas du pipo. Je connais des bases qui sont mirrorées en France et en Angleterre par exemple, a chaud, au cas ou ...
Maintenant en terme de perfs, il faut bencher sa propre application. Il faut savoir qu'au temps d'oracle 7, les requetes sql des applis etaient souvent ecritent de facon a faire produire le bon code par l'optimiseur oracle (comme Alan Cox ecrit du C de facon a ce que gcc produise l'assembleur qui va bien derriere). Puis oracle a changé d'optimiseur de requetes ....
Donc je disais,
-il n'y a pas de vérité absolue en termes de bench. PostgreSQL bat certainement oracle pour plein d'applis, oracle va certainement plus vite que PostgreSQL pour plein d'autres ....
-il ne faut pas sous estimer les autres aspects (features) et les contraintes d'exploitation (vaccumm ?).
Maintenant c'est clair, si PostgeSQL fait le taf, je ne vois pas pourquoi j'irai investir dans des licenses Oracle !!
[^] # Re: Oracle et Java
Posté par Gloo . Évalué à 1.
Ca veut dire que postgresql n'est fait que pour ca ?
http://www.pgsql.com/user_gallery/(...)
J'ai eu aussi un contact avec une boite 2500+ salariés, implenté un peu partout en france qui utilise postgresql. Et, étrangement, sur leur site tu trouves des outils de migration oracle -> postgresql.
Arrête de raconter des conneries. Oracle, c'est très souvent overkill.
Bonjour chez toi.
[^] # Re: C - -
Posté par Étienne . Évalué à -2.
Franchement, non mais vraiement franchement, le c++ ca pulpaté.
Moi je vois que 2 cas dans la vie :
- soit on veut être efficace et on programme en assembleur (regardez moi ces sodomiseurs de drosophiles qui codent un kernel en C ... je me marre)
- soit on veut faire des applis vraiement pro et là on se rabat sur un bon script php et du XML comme format universel.
Une fois qu'on est d'accord sur ces bons principes de base, on peut se concentrer sur ses algorithmes, son code et y'a même plus besoin de débuggage.
[^] # Re: C - -
Posté par Moby-Dik . Évalué à 0.
# Un nouveau paradigme : la corbeille
Posté par Moby-Dik . Évalué à 10.
Le ramasse-miettes a fait ses preuves en termes de gestion avancée de la mémoire, mais il commence en même temps à montrer ses limites. Notamment, le problème numéro un est qu'il ne donne pas le droit à l'erreur, ce qui est problématique quand on fait des erreurs.
Je propose donc un nouveau paradigme de gestion mémoire. Avec la corbeille, l'objet désalloué n'est pas détruit tout de suite. Au contraire, il est placé dans une corbeille. Ainsi, le programme peut éventuellement le récupérer s'il se rend compte qu'il a fait une erreur. C'est un progrès inestimable dans la programmation de haut niveau, qui mettra probablement Java au niveau de Smalltalk et oCaml réunis.
La version actuelle de la corbeille nécessite Swing, AWT, et une souris deux boutons.
[^] # Re: Un nouveau paradigme : la corbeille
Posté par PLuG . Évalué à 4.
De plus on pourrait paramétrer la durée de rétention des objets dans la corbeille: de quelques heures à plusieurs jours, voire à jamais.
Ce n'est pas un probleme, avec le cout dérisoir de la ram de nos jours, et l'avancée des techniques "hot plug", notre language d'avenir assurera une facilité de développement sans précédent.
Bien sur il faudra une machine avec barettes de ram hot-plug pour etendre la ram régulièrement sans reboot, mais c'est le prix du progrès !!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.