IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

[Débat] C++ vs Java


Sujet :

Débats sur le développement - Le Best Of

  1. #841
    Expert éminent

    Inscrit en
    novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    Comme je l'ai dit la différence est surtout qu'en Java tout est virtuel par défaut à l'inverse du C++...
    On peut changer le defaut en Java? Il me semblait que non (en particulier final remplit une partie des besoins mais pas tous en ce qui concerne les membres non virtuels).

    Mais de toute manière je pense que ce ne sera jamais le cas car cela ne rentre pas dans la philosophie du langage. D'ailleurs c'est ce qu'on peut lire sur cette RFE concernant l'héritage multiple :
    Tout comme il ne devait pas avoir de genericite, ou que les flottants devaient fournir des resultats identiques sur toutes les implementations. Deux choses qui ont ete changees.

    Je ne suis pas un grand fan de l'heritage multiple -- surtout que la version restreinte de Java connue sous le nom d'interface remplit la plupart des besoins. Mais c'est uniquement la plupart et la version restreinte l'etait un peu trop a mon gout la derniere fois que j'ai regarde.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  2. #842
    Expert éminent

    Inscrit en
    novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    Par défaut
    Citation Envoyé par deltree Voir le message
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
                            Java  C++   Pour                               Contre
    Réflexivité               O    N   Exécution et chargement dynmique  Compilation difficile et code plus lent
    Héritage multiple         N    O   meilleur factorisation            Code compliqué, ambigu et Contournement possible par délégations
    Generics/templates        O    O   Code + modulaire et pas de casts  Compliqué
    Garbage collector         O    N   Mémoire mieux gérée               Désallocation plus lente et mal maitrisée
    etc.
    Deux remarques sur le tableau.
    - Generic/template: les modeles de Java et de C++ sont tres differents. Celui de C++ est beaucoup plus puissant -- et la difference de puissance va s'agraver avec C++0X. Celui de Java permet une implementation partagee -- effet qu'il est possible en C++ en codant un peu plus d'une maniere tres stylisee, un cible evidente pour la generation automatique de code si le besoin s'en fait sentir. Ton avantage (code + modulaire et pas de cast) oublie le surcroit de puissance du C++, et l'avantage qui me semble tres important de la verification statique des types. Au fait, en quoi les templates sont compliques?

    - GC: je ne suis pas d'accord que la memoire est mieux geree. Le GC c'est diminuer le cout d'implementation en le payant principalement par une plus mauvaise gestion de la memoire occupee. Et si je n'ai rien contre le GC employe a bon escient, il a un risque fort: de faire croire que la gestion de la memoire est automatique (alors qu'il faut continuer a concevoir dans le domaine -- meme si l'implementation est simplifiee) et donc d'utiliser un ownership partage quand ce n'est pas ce qu'il faut.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  3. #843
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 182
    Points
    23 182
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Jean-Marc.Bourguet Voir le message
    On peut changer le defaut en Java? Il me semblait que non (en particulier final remplit une partie des besoins mais pas tous en ce qui concerne les membres non virtuels).
    En effet : si le mot-clef final empêche seulement la méthode d'être redéfini dans une classe fille. Cette limitation est seulement dû à l'absence d'héritage multiple.



    Citation Envoyé par Jean-Marc.Bourguet Voir le message
    Tout comme il ne devait pas avoir de genericite,
    La généricité existe dans tout les langages objets

    Je rigole je comprend bien que tu parles des Generics ! En fait lorsque tu regardes la RFE correspondante tu vois que dès le début les avis était positif. Et si cela a pris autant de temps c'est surtout parce que l'implémentation devait permettre une compatibilité avec les API et application existante :
    Parameterization can indeed be very useful. In considering the various proposals, we are particularly concerned about the impact of such a large change on our customers, especially with respect to compatibility and stability.
    C'est pour cela qu'on a des Generics et non pas des Templates

    a++

  4. #844
    Expert éminent

    Inscrit en
    novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : novembre 2005
    Messages : 5 145
    Points : 6 911
    Points
    6 911
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    La généricité existe dans tout les langages objets
    C'est encore un de ces mots surcharges. Je l'utilisais dans le sens de polymorphisme parametrique.

    Je rigole je comprend bien que tu parles des Generics ! En fait lorsque tu regardes la RFE correspondante tu vois que dès le début les avis était positif.
    Je parle de commentaires tres explicites fait vers 1996-1997 par des gens de Sun. J'ai jamais fait serieusement du Java, mais je regarde le langage de plus ou moins loin quasiment depuis qu'il est sorti de Sun. Apparemement il y a eu un changement d'opinion rapide, a moins que tout le monde n'etait pas du meme avis; il n'est pas impossible non plus qu'il y ait eu un aspect marketing dans la presentation.
    Les MP ne sont pas là pour les questions techniques, les forums sont là pour ça.

  5. #845
    Membre confirmé
    Inscrit en
    mai 2007
    Messages
    335
    Détails du profil
    Informations forums :
    Inscription : mai 2007
    Messages : 335
    Points : 510
    Points
    510
    Par défaut
    Citation Envoyé par Jean-Marc.Bourguet Voir le message
    Deux remarques sur le tableau.
    - Generic/template: les modeles de Java et de C++ sont tres differents. Celui de C++ est beaucoup plus puissant -- et la difference de puissance va s'agraver avec C++0X. Celui de Java permet une implementation partagee -- effet qu'il est possible en C++ en codant un peu plus d'une maniere tres stylisee, un cible evidente pour la generation automatique de code si le besoin s'en fait sentir. Ton avantage (code + modulaire et pas de cast) oublie le surcroit de puissance du C++, et l'avantage qui me semble tres important de la verification statique des types. Au fait, en quoi les templates sont compliques?

    - GC: je ne suis pas d'accord que la memoire est mieux geree. Le GC c'est diminuer le cout d'implementation en le payant principalement par une plus mauvaise gestion de la memoire occupee. Et si je n'ai rien contre le GC employe a bon escient, il a un risque fort: de faire croire que la gestion de la memoire est automatique (alors qu'il faut continuer a concevoir dans le domaine -- meme si l'implementation est simplifiee) et donc d'utiliser un ownership partage quand ce n'est pas ce qu'il faut.
    D'accord, j'ai voulu faire cours car le garbage a déjà été abordé ainsi que les problèmes de générics, et on abordait les problèmes de réflexivité.
    Quand tu dit "l'implémentation est simplifiée" c'est une bonne formule pour résumer l'avantage du GC.
    Par "pas de cast" je voulais en effet dire vérification statique des types: qu'est-ce qui fait le srucroit de puissance du C++ dans ce cas?

    Pour répondre à ta question: les generics sont complexes en Java quand on transmet le type generics d'une classe à l'autre avec des wildcards, exemple sur une méthode max de type collection:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    public static <T extends Comparable<? super T>> 
            T max(Collection<T> coll)
    http://java.sun.com/docs/books/tutor...s/morefun.html
    Outre la syntaxe (beurk) je ne suis pas sûr que les 3/4 des programmeurs s'intéressent vraiment à utiliser les bons wildcards, la plupart vont restreindre la fonction max à un "T extends Comparable<T>"

    Si on ajoute à ça des générics à 2 types, par exemple des classes utilisant des Map, on se tire des balles.

  6. #846
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 062
    Points : 16 062
    Points
    16 062
    Par défaut
    Citation Envoyé par deltree Voir le message
    Outre la syntaxe (beurk) je ne suis pas sûr que les 3/4 des programmeurs s'intéressent vraiment à utiliser les bons wildcards, la plupart vont restreindre la fonction max à un "T extends Comparable<T>"

    Si on ajoute à ça des générics à 2 types, par exemple des classes utilisant des Map, on se tire des balles.
    Plus ca va, plus la syntaxe de Java commence a devenir complexe. Les generics etaient vraiment indispensables, donc j'accepte la surcharge syntaxique necessaire.

    Les Wildcards et les annotations, franchement j'aurais pu m'en passer.

    Et quand je vois qu'ils veulent rajouter des "closures" (ou similaires), ca va devenir franchement complexe. On risque de retomber dans les travers du C++: "on peut tout faire... a condition de savoir le faire."
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  7. #847
    Membre éclairé Avatar de HanLee
    Profil pro
    Inscrit en
    mai 2004
    Messages
    738
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2004
    Messages : 738
    Points : 870
    Points
    870
    Par défaut
    > Jedai : pour ta réponse d'il y a longtemps : si, je suis de ton avis .

    Citation Envoyé par pseudocode Voir le message
    Et quand je vois qu'ils veulent rajouter des "closures" (ou similaires), ca va devenir franchement complexe. On risque de retomber dans les travers du C++: "on peut tout faire... a condition de savoir le faire."
    Dans ce cas de figure précis, là je te comprends pas.

    Généralement, les choses comme ça qui viennent des langages fonctionnels, c'est bénéfique, en terme d'expressivité et de concision.

    Closures, lambda, etc... : tout tourne autour des fonctions, ça permet donc d'exprimer sa pensée plus directement, sans détours et approximations syntaxiques via des classes locales ou anonymes...

    Et la syntaxe est quasiment la même que pour des classes ou des fonctions, donc la complexité...

    Difficile d'en abuser jusqu'à les dénaturer : les closures, c'est pour quelque chose de local, temporaire, qu'on utilise principalement pour faire sous-traiter une action par quelque chose d'autre.

  8. #848
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 062
    Points : 16 062
    Points
    16 062
    Par défaut
    C'est toujours beau, propre et clair sur le papier... et puis arrive la réalité:

    vaut il mieux une classe anonyme ou une closure ?
    Est ce qu'on peut heriter d'un closure ? l'overloader ? l'overrider ?
    Est-ce qu'on peu invoquer une closure par reflection ?

    Que fait cette très simple closure ?
    Code java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    public static <T,U> void mystere(Map<T,U> m,
            {T, U=> } block) {
        for (Iterator<T> it = m.keySet().iterator(); it.hasNext(); ) {
            T key = it.next();
            block.invoke(key, m.get(key));
        }
    }

    Je prefere que Java reste simple... pour la complexité, il reste toujours le C++ !
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  9. #849
    Membre éclairé Avatar de HanLee
    Profil pro
    Inscrit en
    mai 2004
    Messages
    738
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2004
    Messages : 738
    Points : 870
    Points
    870
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    C'est toujours beau, propre et clair sur le papier... et puis arrive la réalité:

    ...

    Est ce qu'on peut heriter d'un closure ? l'overloader ? l'overrider ?
    Est-ce qu'on peu invoquer une closure par reflection ?
    Et pourquoi tu voudrais faire ça ?
    L'idée derrière, c'est que closure est une fonction, et non une classe. Est-ce que ça a un sens de vouloir en hériter, la redéfinir ?

    Ensuite, est-ce qu'on peut vraiment faire ce à quoi tu penses en Java ?
    Si oui alors ce sont pas des belles closures... J'interdirais ça.

    ---------

    Et pour ta fonction, si tu penses qu'elle est déroutante pour les programmeurs, je pense que la difficulté vient juste qu'il faut s'habituer à manipuler des "first-class functions", ce que les Java-men ne font pas souvent à cause du langage.

    Mais on le fait tout le temps quand on veut trier quelque chose, quand on veut faire des callbacks en C, etc. !

    Si on a manipulé un peu de maths élémentaires dans sa vie (théorie des ensembles + fonctions, c'est tout), alors on sait faire l'amalgame immédiatement !

    Donc en prenant ton exemple, on comprendrait vite que ta fonction n'est qu'un for_each (ou iter...) en raisonnant de cette manière par exemple :
    - on considère que Map<T, U> m est équivalent à une application m : T' -> U, où T' inclus dans T est fini
    - block une fonction à effet de bord sur T * U

    alors ta fonction mystère veut dire :

    pour tout x appartenant à T, on exécute l'instruction block(x, m(x));

  10. #850
    Nouveau Candidat au Club

    Profil pro
    Inscrit en
    juin 2003
    Messages
    449
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : Afghanistan

    Informations forums :
    Inscription : juin 2003
    Messages : 449
    Points : 0
    Points
    0
    Billets dans le blog
    1
    Par défaut
    Même si les closure aporte une complexité, elle permetent de facilité les itérations et l'écriture du code, moi je trouve que c'est ce qui manque à java.

    Par contre que c'est vrai que la syntaxe de java ce complexifie et tend faire les même erreurs que C++.

    C'est pour ca que j'apprécis bcp Smalltalk qui a une syntaxe ultra simple et efficace.

  11. #851
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 062
    Points : 16 062
    Points
    16 062
    Par défaut
    Citation Envoyé par HanLee Voir le message
    Et pourquoi tu voudrais faire ça ?
    L'idée derrière, c'est que closure est une fonction, et non une classe. Est-ce que ça a un sens de vouloir en hériter, la redéfinir ?
    Il n' y a aucune raison de "vouloir" le faire. Mais si on "peut" le faire, alors cela ce fera (loi de murphy).

    L'idée de Java c'etait justement de faire en sorte que ca n'arrive "jamais", car on "ne peut pas" le faire... moindre danger => interdiction. C'est tres restrictif, mais c'est sécurisant. A partir du moment ou tu as 3 methodes pour faire un foreach, il y en a 2 qui ne sont pas les meilleures... et comment on décide laquelle prendre ? Des nouvelles règles, des nouvelles bonnes pratiques, des nouveaux DP... bref plus de chose a se rappeler, donc plus de risque d'erreur.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  12. #852
    Membre éclairé Avatar de HanLee
    Profil pro
    Inscrit en
    mai 2004
    Messages
    738
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2004
    Messages : 738
    Points : 870
    Points
    870
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    Il n' y a aucune raison de "vouloir" le faire. Mais si on "peut" le faire, alors cela ce fera (loi de murphy).
    Et dans les faits ? Si Java ne le permet pas, tant mieux, donc aucune raison d'en avoir peur.

    L'idée de Java c'etait justement de faire en sorte que ca n'arrive "jamais", car on "ne peut pas" le faire... moindre danger => interdiction. C'est tres restrictif, mais c'est sécurisant. A partir du moment ou tu as 3 methodes pour faire un foreach, il y en a 2 qui ne sont pas les meilleures... et comment on décide laquelle prendre ? Des nouvelles règles, des nouvelles bonnes pratiques, des nouveaux DP... bref plus de chose a se rappeler, donc plus de risque d'erreur.
    Ben, un algorithme, tu peux parfois l'écrire en itératif ou en récursif.
    Java a-t-il interdit le style récursif ?

    Idem, exécuter un foreach peut se faire en style fonctionnel ou impératif. Dans beaucoup de cas, l'un n'est pas meilleur que l'autre, mais parfois l'un est plus adapté et élégant que l'autre.

    C'est inévitable, à partir du moment où tu as un langage à orientation impérative qui te permet de manipuler des fonctions/méthodes.

    Enfin, on peut considérer que le style avec classe anonyme n'était qu'un hack, tout comme C++ simule cela de la même manière avec les classes locales.

  13. #853
    screetch
    Invité(e)
    Par défaut
    Citation Envoyé par pseudocode Voir le message
    Personnelement, je trouve qu'il est plus dur de faire un "bon" programme C++, qu'un "bon" programme Java.

    par "bon", je parle de lisibilité, de maintenabilité, d'extensibilité, de respect des paradigmes/regles, de fiabilité, et bien sur de perfomances.

    Le C++ permet de TOUT faire, fonctionnellement parlant. Mais en terme de lisibilité, fiabilité, ... il faut etre un expert dans beaucoup de domaine:
    - la programmation imperative (type C, avec variables globales)
    - la programmation objet (type C++, avec instances de classes)
    - la gestion structure/mémoire (struct/union/class, malloc/free/new/delete, tableaux/collections, pointeurs/reference/valeur)

    Le Java permet de faire moins de choses que le C++, fonctionnellement parlant (pas de jeux, pas de drivers, ...) . Mais il est beaucoup plus facile de faire un "bon" programme car seule la maitrise du paradigme OO est necessaire.

    Une fois que le design d'une classe est choisi (UML/Pattern), il n'y a generalement qu'une seule maniere de la coder (syntaxe restreinte, compilateur stricte, JDK standard).

    En C++, on a toujours des "choix" possibles au mement de coder. Ce sont ces choix qui permettent des optimisations au niveau "performance" qu'on ne pourra pas faire en Java. Le probleme, c'est qu'un non-expert risque souvent de faire un mauvais choix pour des raisons de facilité d'ecriture.

    Bien sur, ca n'empeche pas qu'il existe des mauvais programme Java (une classe, tout en static ) et de tres bon programme C++. Mais, de par mon experience, je trouve qu'il est plus facile d'analyser, comprendre et corriger une appli Java qu'une appli C++.

    Petite question: Combien de règles faut-il respecter pour faire un "bon" programme C++ ? Et Java ?
    salut, je deterre!

    il est difficilement soutenable que laisser le choix de la methode est un desavantage. Je concois que dans le mauvais cas, le C++ permet de cumuler les bourdes.

    Mais le fait que C++ offre plus de paradigmes de programmations permet de choisir la meilleure solution pour obtenir un resultat. Du temps ou j'utilisais java, il n'y avait pas de templates; donc je ne sais pas ce que c'est devenu. Mais la programmation générique en C++ a sauvé mes petites fesses des miyards de fois et tant qu'il n'y aura pas de moteur de template aussi puissant en java qu'en C++, je ne me mettrais pas a java.

    Pour conclure, C++ permet d'ecrire des programmes partant de la nullitude la plus crasse pour atteindre une qualité correcte. En java, le pire que l'on puisse faire est mediocre et le mieux que l'on puisse faire est mediocre mais un peu mieux.

    Nous sommes supposes maitriser le C++ et ne plus ecrire la nullitude; meme si de nombreuses choses sont perfectibles dans ce que j'ecris, je l'ecris mieux que je ne pourrais l'ecrire en java avec les memes connaissances; car Java et son paradigme OO permet de resoudre des problemes de facon moins concises que les templates du C++.

    En revanche j'aurai pas craché sur l'introspection en C++, j'ai fini par la coder moi meme et ca alourdit mes interfaces.

  14. #854
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : décembre 2006
    Messages : 10 062
    Points : 16 062
    Points
    16 062
    Par défaut
    Citation Envoyé par screetch Voir le message
    salut, je deterre!
    Amis zombis, bonsoir...

    il est difficilement soutenable que laisser le choix de la methode est un desavantage. Je concois que dans le mauvais cas, le C++ permet de cumuler les bourdes.
    Je n'ai pas dit que c'etait un désavantage, mais juste un risque supplémentaire.

    Pour conclure, C++ permet d'ecrire des programmes partant de la nullitude la plus crasse pour atteindre une qualité correcte. En java, le pire que l'on puisse faire est mediocre et le mieux que l'on puisse faire est mediocre mais un peu mieux.
    ?! C'est pas un peu exagéré, quand meme ? J'ai beau aimer le C++, je peux quand meme pas dire que JBoss, Struts, Tomcat, Spring ou Hibernate sont "mediocres".

    Ma conclusion du jour:

    J'aime le C++ pour des raisons techniques.
    J'aime Java pour des raisons pratiques.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  15. #855
    Inactif  
    Profil pro
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 56
    Localisation : France

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 467
    Points
    2 467
    Par défaut
    Citation Envoyé par Kujara Voir le message
    Ouch, tellement faux ...

    2 façons d'optimiser, algorithme, et implementation de l'algorithme.

    Pour l'algo lui meme, le compilateur ne fait rien.
    Pour l'implementation, le compilateur n'optimise que sur du court terme ( sur la longeur d'une fonction, par exemple).

    Pour n'importe que bout de code plus long que ton exemple, rien ne peut remplacer un cerveau humain .....
    C'est très loin d'être évident ce que tu dis.
    En fait en général le compilateur C écrit du meilleur code (plus rapide) que du code assembleur à la main.

    Certes la règle n'est pas valide à 100%. Mais l'ordinateur gagne plus souvent actuellement que l'humain aux jeux des optimisations. La recherche a bien plus évolué que tu ne le penses visiblement. Pseudocode ne donnait pas une règle définitive, mais je suis complètement de son avis. De nos jours les problèmes de performances sont principalement dus à des erreurs de conception et non à du tweaking (cf. les chiffres compilés par Boehm)

    La performance est devenu un enjeu de moindre importance dans l'industrie du logiciel, si on met de côté des aspects comme le calcul scientifique. Mais ce dernier ne représente pas qu'une petite part de l'industrie. Le problème est dans les algorithmes et plus beaucoup dans les petites optimisations.

    Maintenant les algorithmes sont fait par des humains. -_- Dire que les algorithmes font mieux qu'un humain moyen, c'est dire que qqun a fait un coup génial, et non que la machine a battu l'humain.

  16. #856
    Inactif  
    Profil pro
    Inscrit en
    juillet 2005
    Messages
    1 958
    Détails du profil
    Informations personnelles :
    Âge : 56
    Localisation : France

    Informations forums :
    Inscription : juillet 2005
    Messages : 1 958
    Points : 2 467
    Points
    2 467
    Par défaut
    Citation Envoyé par super_navide Voir le message
    [...]
    Par contre que c'est vrai que la syntaxe de java ce complexifie et tend faire les même erreurs que C++.

    C'est pour ca que j'apprécis bcp Smalltalk qui a une syntaxe ultra simple et efficace.
    On s'entend que Java est le digne héritier de Smalltalk ??
    Ils ont pris la syntaxe du C/C++ pour des raisons commerciales et pour attirer l'industrie, mais la philosophie est celle du Smalltalk. Mes vieux collègues (pourvus qu'ils ne me lisent pas ) adeptes de la première heure de Smalltalk ne me démentiront pas. Bon cependant, attention je n'ai pas dit que Java est Smalltalk. Ces mêmes collègues ont tendances à détester Java... tout autant que C++ d'ailleurs.

  17. #857
    Nouveau Candidat au Club

    Profil pro
    Inscrit en
    juin 2003
    Messages
    449
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : Afghanistan

    Informations forums :
    Inscription : juin 2003
    Messages : 449
    Points : 0
    Points
    0
    Billets dans le blog
    1
    Par défaut
    Java est l'héritier de Smalltalk et du C++.
    Mais je préfère le couple Smalltalk + C(C++) qui je pense est bien meilleur que java seul ou C++ seul.

    N'importe qui peut programmer en Smalltalk même un enfant.

    Mais je dois dire que Java aujourd'hui est très puissant il y a une communauté de développeur importante et les environements de développement sont très puissant (mais un peut lourd ) et il y a bcp de framework autour.

    je me suis mis a java à partir de la 1.5 car je trouve que ce qu'il manquait a java c'étais les générics.

  18. #858
    Nouveau Candidat au Club

    Profil pro
    Inscrit en
    juin 2003
    Messages
    449
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : Afghanistan

    Informations forums :
    Inscription : juin 2003
    Messages : 449
    Points : 0
    Points
    0
    Billets dans le blog
    1
    Par défaut
    Existe-il en C++ un framework comme bcel ou asm.objectweb de java qui permet de générer des classes en runtime.
    Je pense que non car j'ai longtemps chercher un tel framework .

  19. #859
    Membre averti Avatar de Kujara
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    262
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : décembre 2006
    Messages : 262
    Points : 327
    Points
    327
    Par défaut
    Citation Envoyé par Garulfo Voir le message
    C'est très loin d'être évident ce que tu dis.
    En fait en général le compilateur C écrit du meilleur code (plus rapide) que du code assembleur à la main.
    En general, oui.Mais dès que tu creuse un peu et que tu commence a faire des choses compliqués....

    La recherche a bien plus évolué que tu ne le penses visiblement
    En tant que professionel, seul les outils actuellement disponibles m'interessent.

    Je me doute bien que quelque part sur cette planete, un groupe de petits malins ont crée un compilateur qui optimise correctement, ou sont en train de.

    Mais pour l'instant, les outils actuels ne le font pas .... ( vc++ 8 sp1, gcc derniere version, etc ...).

    Le problème est dans les algorithmes et plus beaucoup dans les petites optimisations
    Quand l'algorithme est connu, et totalement optimisé ( prouvé mathematiquement comme optimal ), la difference est dans l'implementation ....

  20. #860
    Membre averti Avatar de Kujara
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    262
    Détails du profil
    Informations personnelles :
    Âge : 38
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : décembre 2006
    Messages : 262
    Points : 327
    Points
    327
    Par défaut
    Citation Envoyé par super_navide Voir le message
    Existe-il en C++ un framework comme bcel ou asm.objectweb de java qui permet de générer des classes en runtime.
    Je pense que non car j'ai longtemps chercher un tel framework .
    Tu peux chercher >.<

    En theorie c'est possible ( assembleur recompilé direct en mémoire, puis sauter sur ces bouts de code).

    Mais c'est tellement contraire aux fondements du c++ .....


    ...



    Maintenant que j'y reflechis, ça pourrait etre très, très amusant ...
    Merci pour l'idée ^^

Discussions similaires

  1. [Débat] Technologie .NET vs JAVA
    Par neo.51 dans le forum Débats sur le développement - Le Best Of
    Réponses: 1047
    Dernier message: 14/01/2019, 16h15
  2. [Débat] .NET vs JAVA/J2EE
    Par tssi555 dans le forum VB.NET
    Réponses: 5
    Dernier message: 10/12/2008, 07h54

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo