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. #1821
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Points : 18 679
    Points
    18 679
    Par défaut
    Citation Envoyé par Ubiquité Voir le message
    Ce qui force un programme Lisp à intégrer un interpréteur ou un compilateur est une propriété que n'a pas Java.
    parce que Java est compilé vers une VM pour sa version desktop... (JavaCard est par exemple bien plus limité dans ses features -- pas de GC par exemple)

    mais quand on voit que .Net a été obligé d'introduire le DLR dans son runtime pour gérer les langages dynamiques, on voit bien que cette contrainte de Common Lisp est dupliquée de manière pragmatique (faire du neuf avec du vieux )
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  2. #1822
    gl
    gl est déconnecté
    Rédacteur

    Homme Profil pro
    Inscrit en
    Juin 2002
    Messages
    2 165
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Juin 2002
    Messages : 2 165
    Points : 4 637
    Points
    4 637
    Par défaut
    Citation Envoyé par Nemek Voir le message
    Il y a une grosse différence entre l'héritage d'une classe et l'implémentation d'une interface : le code à exécuter est forcément dans la hiérarchie d'héritage.
    En Java oui.

    Mais justement ma réponse à la question "comment ça se passe dans d'autres langages ayant fait le même choix que Java (i.e. pas d'héritage multiple mais implémentation de multiples interface)" était qu'au moins un langage, le D, permet d'avoir du code à exécuter dans l'interface à condition que la méthode en question soit finale. Ça me semble une bonne idée.

  3. #1823
    Membre régulier
    Homme Profil pro
    Développeur .NET/C/C++
    Inscrit en
    Septembre 2007
    Messages
    71
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur .NET/C/C++
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Septembre 2007
    Messages : 71
    Points : 122
    Points
    122
    Par défaut
    Citation Envoyé par Nemek Voir le message
    Je parlais surtout des pointeurs dont il faut faire particulièrement attention. Alors peut-être qu'avec le temps ca devient ultra intuitif en ayant des patterns simples et efficaces ; en attendant on doit focaliser une part d'attention à ça, ce qui nous prive de nous focaliser sur autre chose. C'est bien ça qu'offre des plateformes comme Java et .Net
    Oui et non. C'est vrai qu'en C++ le développeur se doit de réfléchir à la durée de vie de ses objets (même si les smarts pointeurs permettent de se simplifier la vie, il reste néanmoins à les utiliser correctement). Après ce n'est pas parce que je dois penser à cela que je ne pense pas au reste. Mais c'est vrai que c'est une charge supplémentaire.
    Et quand je vois le nombre d'applications qui se terminent en Core Dump, je me dis que tout le monde ne les manipules pas si bien que ça.
    Cependant il n'est pas rare des applications Java qui ont de graves fuites mémoires (surtout en environnement modulaire).
    Ce qui montre que l'on doit quand même y réfléchir un minimum même en java (et contrairement à ce que l'on pourrait croire de prime abord).
    Tiens à ce sujet, un petite question :
    Existe-t-il en java un equivalent au destructeur en c++? Parce qu'en ce qui concerne la gestion des ressources (pas seulement de la mémoire mais aussi tout ce qui est accès à un fichier, connexion réseau, thread, ...) je trouve que c'est quelque chose de quasi indispensable.

    La permissivité (ou le laisser-aller/faire) ne sont pas, par expérience, didactique. Au contraire, plus tu laisses de liberté aux gens et plus ils en prennent plus que d'être ultra-rigoureux.
    Et plus on leur tapes dessus ensuite parce qu'ils ont fait n'importe quoi

    Non ca me choque pas car
    1. ce n'est pas à nous de déterminer si une infinité d'objet dans une infinité de contexte ont un lien ou pas.
    2. si je veux les mettre dans un même panier c'est que je considère qu'il existe un lien
    3. dans le cas de Java et des collections, ca rend le code générique, compatible avec toutes les classes et légèrement optimisé
    Sauf que dans le contexte d'un programme donné, 2 objets peuvent avoir un lien ou ne pas en avoir. Si l'on reprend l'exemple des voitures, on peut très bien concevoir avoir une voiture, un camion ou un vélo dans une même liste. Par contre, je peux très bien considérer qu'un feux de signalisation n'a rien à y faire. Aussi je préfère que ce soit mon compilo qui m'envoie balader parce que je me suis trompé à un moment dans mon code plutot que de devoir tester mon appli puis chercher pendant des heures pour me rendre compte de mon erreur.
    Après, je me trompe peut-être mais les generics en java doivent permettre d'arriver au même résultat non? (j'entends par là une erreur à la compilation). Dans ce contexte, j'aurai même tendance à dire que le fait que tout object hérite de la classe object etait surtout une nécéssité à une époque ou les générics n'existaient pas encore.
    Quoi qu'il en soit, je considère perso que toute map, liste ou autre conteneur se doit d'être typés un maximum (via les générics en java et les templates en C++) et que les conteneurs contenant des objects sont à proscrire.
    Enfin, je dirai qu'il ne faut pas forcément que tout soit objet pour pouvoir avoir un code générique. Après tous, les conteneurs de la STL y arrivent très bien.


    J'admet volontiers qu'il n'y a pas de nécessité d'avoir une base unique. Je dis en revanche que cela a ses avantages. Cela sert la cause de Java et non le contraire. Quiconque manipule un peu l'API se rend compte qu'Object n'est pas dénué de sens et de fonctionnalité contrairement à void.
    N'oublie pas non plus que Object possède une méthode getClass() (qui remettra sûrement cause beaucoup de piliers de OO) qui permet d'en savoir beaucoup sur une instance donnée.
    Pour ce qui est de void* (et non void ), son utilisation est à proscrire autant que possible.
    Pour la méthode getClass, le C++ utilise un opérateur pour obtenir le type d'une variable donnée. Après, il est clair que les possibilités en la matière en c++ sont très limitée. Mais bon. Je ne suis pas un fan de la reflection de toute façon.

    Je suis peut-être un peu bisounours aussi dans l'âme mais je pense que quelqu'un de son "niveau" doit être apte à comprendre OO, d'autant plus s'il se permet d'y porter un jugement de valeur. Bon après je connais pas du tout le type ; je veux pas dire personnellement mais dans l'ensemble (l'image qu'il dégage, etc). C'est peut-être un petit con : tu me confirmeras ou pas !
    Bof, perso quand je vois ce qu'il a écrit, j'ai quand même quelques doutes. En fait, j'ai un peu l'impression qu'il jette le bébé avec l'eau du bain. Tout n'est pas parfait en C++, mais quand on le compare avec le C, le C++ apporte quand même beaucoup de facilités je trouve. (le problème étant qu'il n'est pas toujours facile de toutes les maitriser).

    Bah dans une "Reference Map", je vois aucune obligation d'avoir des clés homogènes
    Ben désolé mais moi j'en vois une!
    Si je veux par exemple utiliser un id (donc un int) afin de stocker différents éléments dans ma map, j'apprécie que mon compilo vérifie ce fait et me prévienne si jamais à un moment donné j'essaie d'y mettre autre chose qu'un entier.
    Après, il est possible que l'on veuille pouvoir utiliser n'importe quoi comme clé dans un cas précis, mais si je sais à l'avance que je n'y pettrai que des entiers, je préfère que mon compilo le vérifie.

    Pour information (et désolé du sacrilège de la syntaxe) mais est-ce que le code suivant compile ?
    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    Foo* foo = ...;
    Bar* bar = ...;
    if (foo == bar) {
      ...
    }
    Je viens de tester avec le code suivant :
    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    int main()
    {
    	int *a;
    	double *b;
    	if(a == b)
    		return 0;
    	else 
    		return 1;
    }
    J'obtient ceci:
    test.cpp: In function ‘int main()’:
    test.cpp:5:10: error: comparison between distinct pointer types ‘int*’ and ‘double*’ lacks a cast [-fpermissive]
    donc non cela ne compile pas (ce qui est à mon sens une bonne chose).
    Par contre, le code suivant compile :
    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
     
    int main()
    {
    	int x = 3;
    	double y = 5;
    	void *a = &x;
    	void *b = &y;
    	if(a == b)
    		return 0;
    	else 
    		return 1;
    }
    Les templates, pwaaa. Et toutes façons ils vont supposer (comme les langages dynamiques) que les membres utilisés existent. Si je prends le cas des HashMap, ton code va supposer que les types qui vont "instancier le template" (?) dispose bien des méthodes de calculs du hash et de comparaison sans qu'ils aient de point commun. Tu ne fais que déclarer des interfaces implicites.
    Tout à fait, et si un membre n'existe pas, on a une erreur à la compilation. C'est par ailleurs tout le sujet des concepts. (car actuellement, quand un membre n'existe pas l'erreur générée par le compilo est difficelent lisible, surtout pour un néophyte).

    Concernant le paradigme générique (s'il s'agit bien de la même chose qu'en Java), il faut bien un point commun. D'ailleurs c'est la raison de la présence de Boost::Any non ?
    Je ne sais pas si c'est le même qu'en java. Mais s'il doit y avoir un point commun, je dirai qu c'est le fait qu'un type donné respecte ou pas tel ou tel concept (lesquels peuvent être vu comme tu l'a fort justement dit comme des interfaces implicites). Cependant les concepts ne font pas (encore) parti du langage.

    Que tu colles ta fonction/procédure dans un namespace Foo::Bar ou une méthode dans une classe foo.Bar, je vois pas la différence
    Si ce n'est que comme dit plus haut les namespaces sont extensibles. Mais c'est vrai qu'au final cela ne change pas grand chose. (Par ailleurs, il m'arrive parfois de préférer avoir des méthodes statiques contenues dans une classe plutot que de les avoir au niveau du namespace.)

    En espérant avoir contribué à faire avancer la discussion
    "Toujours en faire plus pour en faire moins"

  4. #1824
    Membre régulier
    Homme Profil pro
    Développeur .NET/C/C++
    Inscrit en
    Septembre 2007
    Messages
    71
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur .NET/C/C++
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Septembre 2007
    Messages : 71
    Points : 122
    Points
    122
    Par défaut
    Citation Envoyé par gl Voir le message
    En Java oui.

    Mais justement ma réponse à la question "comment ça se passe dans d'autres langages ayant fait le même choix que Java (i.e. pas d'héritage multiple mais implémentation de multiples interface)" était qu'au moins un langage, le D, permet d'avoir du code à exécuter dans l'interface à condition que la méthode en question soit finale. Ça me semble une bonne idée.
    Je reconnais aussi qu'il s'agit là d'un bon compromis. (même si perso je préfère disposer de l'héritage multiple, et ce malgré le fait qu'en pratique son utilisation reste marginale).
    "Toujours en faire plus pour en faire moins"

  5. #1825
    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 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par bountykiler Voir le message
    Existe-t-il en java un equivalent au destructeur en c++? Parce qu'en ce qui concerne la gestion des ressources (pas seulement de la mémoire mais aussi tout ce qui est accès à un fichier, connexion réseau, thread, ...) je trouve que c'est quelque chose de quasi indispensable.
    Il y a un mécanisme proche du destructeur : la finalisation.
    Mais elle ne doit pas être utilisé pour cela (ou alors en garde fou), car on ne maitrise pas le moment précis où la finalisation aura lieu (puisque cela dépend du GarbageCollector).

    A la place il faut utiliser la syntaxe try/finally afin de libérer explicitement la ressource :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    	InputStream input = new FileInputStream("file")
    	try {
    		// lecture du fichier
    	} finally {
    		input.close();
    	}
    A noter que Java 7 a introduit une nouvelle syntaxe pour automatiser cela : le "try-with-ressource" :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    	try (InputStream input = new FileInputStream("file")) {
    		// lecture du fichier
    	}


    Citation Envoyé par bountykiler Voir le message
    Après, je me trompe peut-être mais les generics en java doivent permettre d'arriver au même résultat non? (j'entends par là une erreur à la compilation).
    Oui : les Generics génèrent pas mal d'erreurs et/ou warning...

    Citation Envoyé par bountykiler Voir le message
    Dans ce contexte, j'aurai même tendance à dire que le fait que tout object hérite de la classe object etait surtout une nécéssité à une époque ou les générics n'existaient pas encore.
    Cela a quand même d'autres avantages que pour les collections (je pense à la reflection par exemple)

    Citation Envoyé par bountykiler Voir le message
    Quoi qu'il en soit, je considère perso que toute map, liste ou autre conteneur se doit d'être typés un maximum (via les générics en java et les templates en C++) et que les conteneurs contenant des objects sont à proscrire.
    Oui en effet.


    Citation Envoyé par bountykiler Voir le message
    Je viens de tester avec le code suivant :
    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    int main()
    {
    	int *a;
    	double *b;
    	if(a == b)
    		return 0;
    	else 
    		return 1;
    }
    Il s'agit de vérification basique du compilateur. Heureusement que tu as la même chose en Java (erreur : incomparable types).


    Citation Envoyé par gl Voir le message
    Mais justement ma réponse à la question "comment ça se passe dans d'autres langages ayant fait le même choix que Java (i.e. pas d'héritage multiple mais implémentation de multiples interface)" était qu'au moins un langage, le D, permet d'avoir du code à exécuter dans l'interface à condition que la méthode en question soit finale. Ça me semble une bonne idée.
    D'après ce que je lit sur wikipedia, ces méthodes final sont non-virtuelle. Donc cela ne pose aucun problème même avec l'héritage multiple.


    Car plus que l'héritage multiple, c'est sur la notion de virtualité des méthodes que Java diffère du C++.

    En C++ toute les méthodes sont non-virtuelle par défaut, et il faut explicitement les marquer comme tel pour qu'elle le deviennent. Cela limite bien les problèmes de l'héritage multiple, car si la méthode parente n'est pas virtuelle on peut utiliser le même nom de méthode sans que cela ne pose de conflit.

    En Java, mis à part les méthodes private, toutes les méthodes d'instances sont virtuelles. En Java le mot clef final sert juste à interdire la redéfinition de la méthode (qui reste quand même virtuelle).
    Donc en cas d'héritage multiple le risque de conflit est très élevé !




    A noter que Java 8 apportera un nouveau concept qui permettra de simuler l'héritage multiple (même si ce n'est pas son objectif initial), via les "Default Methods".

    Le premier objectifs des "Default Methods" est de permettre l'évolution des interfaces existantes en y ajoutant des méthodes avec un code par défaut qui sera utilisé uniquement dans le cas où la classe n'implémente pas la méthode.

    Bref : on pourrait mettre du code dans une interface.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    public interface Iterable<T> {
    	
        public Iterator<T> iterator();
        
        public boolean isEmpty() default {
        	return !iterator().hasNext();
        }
    }

    Au niveau de la résolution c'est beaucoup plus simple car la moindre implémentation dans une classe de la hiérarchie prendra obligatoirement le pas sur la méthode par défaut de l'interface.

    Le seul problème qui pourrait survenir serait celui de deux interfaces distinctes avec la même méthode disposant d'un code par défaut différent...



    a++

  6. #1826
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Points : 18 679
    Points
    18 679
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    A noter que Java 8 apportera un nouveau concept [...] les "Default Methods" [...]

    Le premier objectifs des "Default Methods" est de permettre l'évolution des interfaces existantes en y ajoutant des méthodes avec un code par défaut qui sera utilisé uniquement dans le cas où la classe n'implémente pas la méthode.

    Bref : on pourrait mettre du code dans une interface.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    public interface Iterable<T> {
    	
        public Iterator<T> iterator();
        
        public boolean isEmpty() default {
        	return !iterator().hasNext();
        }
    }
    [...]

    Le seul problème qui pourrait survenir serait celui de deux interfaces distinctes avec la même méthode disposant d'un code par défaut différent...

    ou alors ils vont obliger à spécifier de quelle interface on hérite par défaut (un peu sur le modèle de C# qui peut spécifier à quelle interface est rattachée une méthode)
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  7. #1827
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    Août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : Août 2005
    Messages : 2 894
    Points : 7 083
    Points
    7 083
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Il faut avouer que ce n'est, effectivement pas du "compile once, run everywhere" mais il est tout à fait possible d'arriver à une compatibilité parfaite en s'astreignant à des règles de codage simplement "correctes".
    Il ne faut pas oublier que tu n'arriveras de toutes manières pas non plus à faire tourner la version "windows" de la JVM dans un environnement *nux !!
    Je voulais juste signaler qu'il n'est pas nécessaire de recompiler pour chaque système et que le principe de VM n'est pas si mauvais si au final vous avez des .so pour les différents *nux et des .dll pour les différents Windows. Car au final c'est bien cela qu'apporte la VM : du code binaire pour chaque plateforme cible.

    Citation Envoyé par koala01 Voir le message
    Je peux t'assurer que l'on compte les endroits où l'on a recours à la compilation conditionnelle (par exemple pour déterminer le système sur lequel on travaille) sur les doigts d'une main, et que cela n'a rien à voir avec l'utilisation de bibliothèque, mais plutot avec l'impossibilité de trouver une application particulière ( excel pour ne pas la citer) sur des machines *nux
    Je te fais largement confiance et je vais même tenter de te croire. Cependant pour que le source soit compatible, t'as bien du code binaire propre à chaque plateforme cible.

    Citation Envoyé par koala01 Voir le message
    j'ai presque envie de dire "mais pourquoi faire le travail à moitié "
    Ou à moitié ne pas le faire

    Citation Envoyé par koala01 Voir le message
    En C++ aussi on est adepte des bibliothèques (hé oui, la traduction de library, c'est... bibliothèque ) tierces
    Bien vu En Java on en utilise à outrance (minimum une vingtaine pour un projet tout juste correct). C'est pareil en C++ ?

    Citation Envoyé par koala01 Voir le message
    Et ce n'est pas cela que l'on recompile à chaque fois
    Mea Culpa. Je pensais que le format de distribution standard c'était le source et non les .so/.dll. Histoire de ne pas proposer 5 000 format de distribution différent.

    Citation Envoyé par koala01 Voir le message
    Le fait est que, bien souvent, "l'héritage mal conçu" (comprend: ne respectant pas LSP ) seraitdevrait être souvent bien avantageusement remplacé par une composition


    Citation Envoyé par koala01 Voir le message
    Mais l'énorme avantage du NVI est qu'il permet de fournir des "points de variation" de manière particulièrement fine...

    Cela permet de respecter d'avantage encore un conseil issu de l'XP: DRY (Don't repeat Yourself ) en évitant, justement, d'obliger la personne qui veut dériver une de nos classes à devoir... reprendre le code de la classe parente pour les parties de variant pas
    On est entièrement d'accord

    Citation Envoyé par koala01 Voir le message
    Si tu le reconnais toi même...
    Cependant je peux tout de même le faire

    Citation Envoyé par koala01 Voir le message
    Mais j'irais même plus loin: ca rend, pour moi, l'utilisation d'un bazooka obligatoire pour chasser une mouche Pas vrai
    Il faut avouer que c'est pas brillant ; mais ... autant que celui d'avoir une interface par comportement et de tout wrapper/bridger/adapter. On critique beaucoup Java pour cela mais finalement ce n'est pas spécifique à celui-ci.
    Et il faut noter que cela fait partie du langage sous la forme de "Byte Code Engineering" ("retravaillé" le Byte Code quoi).

    Le problème en fait des NVI, est-ce vraiment de l'héritage ou bien de la méta-programmation ?
    J'aimerai bien savoir comment la méta-programmation est intégré dans les autres langages (y compris C++) !

    (Soit dit en passant, la programmation par aspect n'a rien d'un bazooka et est en fait assez trivial).

    Citation Envoyé par koala01 Voir le message
    Pourquoi l'aurait il évoqué dans un cours de java, alors que tout dans java tend à minimiser l'importance de ce principe, alors que c'est (en réalité) le premier de tous
    J'ai eu tout de même des cours de COO, ca utilisait la syntaxe UML/Smalltalk/Eiffel pour la partie application ...

    Citation Envoyé par koala01 Voir le message
    Ou du moins que la marge de manoeuvre des sous-types concernant le contrat est fortement limitée:
    1. Les préconditions ne peuvent pas être renforcées dans le sous type
    2. Les postconditions ne peuvent pas être allégées dans le sous type
    3. Les invariants du type de base doivent etre respectés dans le sous type.

    Il y a des chances que ce soit à cause de cela, en effet
    Bah autre les types de paramètres, de retour et d'exception, il n'y a pas de pré/post-conditions et invariants en Java. Il y a bien un mot clé "assert" mais c'est rattaché au corps des méthodes et non aux méthodes elles-mêmes ...
    On doit donc le faire en "conception" (comprendre par organisation du code).

    Citation Envoyé par koala01 Voir le message
    Il y a des chances que ce soit à cause de cela, en effet
    En fait, en essayant de repenser aux 10 dernières fois (environ) où j'ai dû faire ça, c'était effectivement pour corriger un bug dans une méthode

    Citation Envoyé par koala01 Voir le message
    Mais, à ta décharge, cela peut remonter vraiment haut, comme à l'obligation qui t'est faite d'hériter, en toutes circonstances, de la classe Object.
    A la décharge de mes profs ... Cependant un peu de culture est un mal nécessaire. Quand je repense aux heures passées sur la "sécurité informatique" (au sens général : infrastructure, bâtiment, formation/sensibilisation du personnel, etc) et sur CMMi, dix minutes à évoquer la base ce n'est pas un grand mal.

    Citation Envoyé par koala01 Voir le message
    Pour ma part, je trouve quelque part presque dommage que la programmation par contrat ne soit pas plus mise en avant... Cela inciterait les gens à se poser les bonnes questions avant de décider qu'il est plus intéressant de recourir à l'héritage là où tout ce qui les intéresse, c'est de récupérer du code, sans être attentif à la "sémantique" de leur classe.
    Je pense que ca enlèverai de la souplesse qui a fait que Java a été très adopté : assez simple à apprendre et utiliser.

    Citation Envoyé par koala01 Voir le message
    Est-ce une raison pour être obligé de les mettre dans une classe, quand on sait que toutes ces fonctions ont de grandes chances de devoir être statiques car pouvant potentiellement ne dépendre d'aucune instance de la classe :question (et tu sais tout le bien que je pense des fonctions statiques)
    Disons que tout doit appartenir à un paquet (namespace, package ou autre), et qu'en Java ce sont les classes qui portent le code. Ca simplifie les choses et comme je l'ai dit, quelle différence entre Foo::Bar::faire() et foo.Bar.faire() ?

    Citation Envoyé par koala01 Voir le message
    Par contre, ce que j'ai beaucoup de mal à accepter, l'aspect systématique de la chose qui apparait en java: même si l'on se dit qu'une map va utiliser le type X comme clé et les types dérivant de Y comme valeur, on n'est jamais à l'abri de l'éventualité que quelqu'un, quelque part dans le code, n'ait pas saisi correctement l'utilisation qui est faite de la map et décide d'utiliser le type A comme clé et le type B commme valeur (A et B n'ayant définitivement rien à voir avec X et Y, tu l'auras compris ), surtout si "pour ne pas te casser la tête", tu as décidé (car tu as le droit de le faire ) d'accepter que la fonction qui s'occupera d'ajouter les élément à ta map prennent des références sur Object tant pour la clé que pour la valeur
    La méthode d'ajout prend bien les types X et Y en paramètre ... Après si tu parles de comment sont implémentés les génériques en Java, je te renvoie à mes réponses précédentes.

    Citation Envoyé par koala01 Voir le message
    Tu peux te mettre à l'abri de ce genre d'erreur par programmation, de préférence en choisissant le type correct pour les arguments, au pire, en vérifiant le type réel des arguments que tu obtiens dans la fonction d'insertion, mais il est "dommage, dirons nous" qu'un langage qui se prétend facile et sécurisant permette qu'un mauvais choix d'un coté et une mauvaise compréhension de l'autre permette à des catastrophes de survenir
    Il existe des collections qui font ça mais Java a fait (depuis un petit moment déjà) le choix de limiter les contrôles et de faire confiance aux développeurs d'utiliser/appliquer ou non les contrôles en fonction du degré de confiance qu'ils ont en leur propre code et de comment les données qu'ils transmettent vont être utilisés.

    Citation Envoyé par koala01 Voir le message
    Tu as, effectivement, du code binaire qui est généré pour chaque type spécialisant un template...
    Mais c'est normal
    Après tout, quand on écrit en C++ une classe proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    template <typename Type>
    c lass MaClass
    {
    };
    et qu'on l'utilise avec les types A, B, et C (tous les trois étant différent ) c'est, au niveau du binaire généré comme si on avait écrit les trois classes (la répétition de code en moins)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    class MaClassA // cas particulier utilisant le type A
    {
    };
    class MaClassB // cas particulier utilisant le type B
    {
    };
    class MaClasseC // cas particulier utilisant le type C
    {
    };
    Disons que c'est bizarre de recompiler la classe "List" à chaque fois que tu en as besoin ... Et cela signifie qu'il te faut le code source ?
    Par ailleurs si tu veux faire du code "générique" sur les listes (ex : un visiteur d'une liste), il te faut faire un template et créé autant de type.

    Citation Envoyé par koala01 Voir le message
    std::list <int> est substituable à std::list<int>
    Pour raviver ma mémoire, il faut bien faire des "typedef" ?

    Citation Envoyé par koala01 Voir le message
    Si le type d'entier (int Vs unsigned int, short Vs unsigned short), oui, bien sur
    ok

    Citation Envoyé par koala01 Voir le message
    Non... C'est pour cela que les collections de la stl n'ont pas vocation à être dérivées
    On ne parle pas d'héritage mais de covariance/contravariance ...

    Citation Envoyé par koala01 Voir le message
    Par contre, tu peux effectivement créer une liste de pointeurs sur Base et insérer un pointeur sur Derivee si Derivee hérite effectivement de Base

    Mais attention, nous sommes là dans un paradigme qui n'a rien à voir avec le paradigme OO, nous abordons le troisième paradigme utilisé par C++ qui est le paradigme générique (celui ou l'on ne sait pas encore le type de valeurs que l'on va utiliser, mais ou l'on sait par contre comment on va comment on va les utiliser )
    Pour information, ca donne quoi en utilisant les génériques plutôt que les templates ?

    Citation Envoyé par koala01 Voir le message
    Justement pas!!!

    Bien au contraire

    Chaque fois que tu vas instancier une classe template avec un type particulier, le binaire correspondant va être généré (en fait, le code de ta classe va être compilé en considérant que l'on utilise le type envisagé).

    Si tu instancie ta classe template avec dix types différent, les vérifications effectuées à la compilation seront effectuées... dix fois (une fois pour chaque type avec lequel ta classe template est instanciée)
    Je signalais seulement, pour être générique, qu'en choississant un point commun dans la hierachie de classe (Object ou pas), tu te retrouves nécessairement avec des instances de type différent (ex: une collection) et que la vérification verifiera seulement si les types sont compatibles en terme de hierarchie. Rien de différent de Java.



    Citation Envoyé par koala01 Voir le message
    L'idée de concept est en fait différente (et a été écartée afin de permettre une sortie "relativement rapide" de la dernière norme en date, pour tout dire )
    L'idée est de se dire "voilà, j'ai besoin d'un concept X" (mettons : le concept de "sérialisabilité" )

    et de continuer "Pour qu'un classe respecte ce concept, il faut qu'elle expose certaines fonctions dont le nom et la signature sont clairement identifiés" ( les fonctions write et read, par exemple, pour le concept de sérialisabilité )

    Pour terminer par "je vais donc vérifier (à la compilation ) que tout objet qui me sera transmis ici dispose bel et bien des fonctions ad-hoc"

    La notion de concept permet donc une vérification "orthogonale" de ton projet car il n'est pas du tout impossible que tu aies une classe SerializableX qui hérite de X ainsi qu'un autre SerializableY qui hérite de Y (mais sans qu'il n'y ait le moindre lien entre la classe X et la classe Y ) dont le seul point commun est d'exposer un certain nombre de fonctions portant le même nom et acceptant un nombre de paramètres identique
    Ok, donc c'est bien de la méta-programmation ... Finalement ca aurait dû prendre quelle forme ?

    Citation Envoyé par koala01 Voir le message
    Ben non, pourquoi
    Les DP bridge, Facade et consors, cela ne te dit rien
    Si bien sûr, d'ailleurs en Java on ne connaît que ça -_-' Cependant on critique justement souvent Java pour ça.

    Citation Envoyé par koala01 Voir le message
    Ce qu'il faut comprendre, c'est qu'aucun langage n'est foncièrement mauvais ni foncièrement bon!!!
    D'un point de vue pure concept/syntaxe/idéologie, je préfère Ruby,C++,C# à Java (uniquement pour ceux que j'ai déjà taté). Cependant notre travail est surtout conditionné par le marché et nos expériences accumulées.
    (Si quelqu'un veut me prendre à l'essai sur l'un des ces trois langages, n'hésitez pas :p).

    Citation Envoyé par koala01 Voir le message
    On peut éventuellement dire qu'un langage sera plus adapté à un secteur qu'à un autre, mais il faut vraiment voir les besoins pour parler de la sorte
    Le plus gros besoin en règle générale c'est la main d'oeuvre et le prix ...

    Citation Envoyé par koala01 Voir le message
    Et malgré tout le mal que j'ai pu dire de java sur mes dernières interventions, je peux te rassurer : je ne le trouve pas forcément pire qu'un autre (ni forcément meilleur d'ailleurs )
    Tout pareil seulement tu critiquais les choix des concepteurs du langage et que tu ne semblais pas comprendre les raisons de ces choix

    Citation Envoyé par koala01 Voir le message
    Cependant, je me demande quelle est la proportion de projets (quel que soit le langage envisagé ) pour lesquels le choix du langage est basé uniquement sur "ce que connait l'initiateur du projet", sur "l'effet de mode" ou sur le fait que c'est, définitivement, le langage le plus adapté aux besoins que l'on doit rencontrer (ou peut etre sur "la tchatche du commercial qui vend le projet ) ...
    5% peut-être.
    Quoiqu'il arrive ~90% doivent être basé uniquement sur l'environnement existant (que ce soit le langage ou pas). Si j'ai déjà des serveurs Oracle, je continuerai à fonctionner sous Oracle. Idem pour l'OS et les logiciels.
    Mon tout premier projet en entreprise (stage + CDD) consistait à migrer une application Cobol sous Windows d'une interface Console à une interface graphique fenêtrée. On a gardé Cobol et les fichiers séquentiels indexées. Alors le commercial/CP militait auprès du client pour remplacer les fichiers séquentiels indexés par une base de données (plus rapide, plus robuste, plus fiable, plus facile à manipuler pour les opérations de maintenance comme le backup, la restauration, la transformation, etc.). Cependant le client a toujours refusé.

    Citation Envoyé par koala01 Voir le message
    Je reste cependant convaincu que le choix d'un langage "de prédilection" reste une affaire de gout et de philosophie personnelle, mais qu'il est malgré tout quasiment indispensable de s'intéresser au moins un tout petit peu aux langages que l'on "apprécie moins", ne serait-ce que pour pouvoir se "dépatouiller avec" en cas de besoin
    Sans forcément regarder les langages ce sont plutôt les paradigmes. Car tant que tu restes dans l'objet/impératif t'arriveras à te dépatouiller en voyant ce qui existe, Internet et les autres membres de l'équipe. Bon sauf si tu dois lancer un nouveau projet mais dans ce cas c'est du suicide
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  8. #1828
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    Août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : Août 2005
    Messages : 2 894
    Points : 7 083
    Points
    7 083
    Par défaut
    Citation Envoyé par bountykiler Voir le message
    Oui et non. C'est vrai qu'en C++ le développeur se doit de réfléchir à la durée de vie de ses objets (même si les smarts pointeurs permettent de se simplifier la vie, il reste néanmoins à les utiliser correctement). Après ce n'est pas parce que je dois penser à cela que je ne pense pas au reste. Mais c'est vrai que c'est une charge supplémentaire.
    Tout temps passé à faire une chose est un temps qui n'est pas passé à faire autre chose (sauf pour les femmes ^_-).

    Citation Envoyé par bountykiler Voir le message
    Ce qui montre que l'on doit quand même y réfléchir un minimum même en java (et contrairement à ce que l'on pourrait croire de prime abord).
    Sauf qu'en Java ca continue de fonctionner et tant que tu n'as pas atteint les limites de la machine (ou celles de la JVM), tu ressens aucune gêne.

    Citation Envoyé par bountykiler Voir le message
    Existe-t-il en java un equivalent au destructeur en c++? Parce qu'en ce qui concerne la gestion des ressources (pas seulement de la mémoire mais aussi tout ce qui est accès à un fichier, connexion réseau, thread, ...) je trouve que c'est quelque chose de quasi indispensable.
    Il n'y a pas d'instruction de destruction. Cependant on peut écrire une méthode "finalize()" qui est appelée quand le Garbage Collector est prêt à supprimer l'instance.
    Comme l'a dit adiGuba, c'est surtout un garde-fou pour nettoyer les ressources que le programmeur aurait omis.

    Citation Envoyé par bountykiler Voir le message
    Et plus on leur tapes dessus ensuite parce qu'ils ont fait n'importe quoi
    Et parce qu'ils ont pas compris ce qu'on leur a pas expliqué


    Citation Envoyé par bountykiler Voir le message
    Sauf que dans le contexte d'un programme donné, 2 objets peuvent avoir un lien ou ne pas en avoir.
    C'est bien ce que je disais

    Citation Envoyé par bountykiler Voir le message
    Si l'on reprend l'exemple des voitures, on peut très bien concevoir avoir une voiture, un camion ou un vélo dans une même liste. Par contre, je peux très bien considérer qu'un feux de signalisation n'a rien à y faire. Aussi je préfère que ce soit mon compilo qui m'envoie balader parce que je me suis trompé à un moment dans mon code plutot que de devoir tester mon appli puis chercher pendant des heures pour me rendre compte de mon erreur.
    Après, je me trompe peut-être mais les generics en java doivent permettre d'arriver au même résultat non? (j'entends par là une erreur à la compilation).
    Effectivement avec les génériques tu te feras jeter si tu veux ajouter un feu dans une liste de véhicules.

    Citation Envoyé par bountykiler Voir le message
    Dans ce contexte, j'aurai même tendance à dire que le fait que tout object hérite de la classe object etait surtout une nécéssité à une époque ou les générics n'existaient pas encore.
    Enfin, je dirai qu'il ne faut pas forcément que tout soit objet pour pouvoir avoir un code générique. Après tous, les conteneurs de la STL y arrivent très bien.
    En Java, même avec les générics, cela reste une necessité pour avoir un code "générique". Car Java n'a pas le principe du template ou des concepts. Il faut un type pour travailler. Par exemple
    • Tout conteneur Java doit pouvoir savoir si deux éléments quelsconque sont égaux (identité de valeur j'ai envie de dire).
    • Toute clé d'une map par hashage (ou élément d'un set par hashage mais ca revient au même puisqu'un HashSet n'est ni plus, ni moins qu'un ensemble de clé d'une map de hashage), doit avoir une méthode de calcul de hashage (en plus de l'identité de valeur).

    Uniquement pour les conteneurs. Si on parle des API de bindings (base de données, XML, interface graphique) c'est la même histoire.

    Citation Envoyé par bountykiler Voir le message
    Quoi qu'il en soit, je considère perso que toute map, liste ou autre conteneur se doit d'être typés un maximum (via les générics en java et les templates en C++) et que les conteneurs contenant des objects sont à proscrire.
    Outre les conteneurs, il arrive qu'un ensemble donné n'est pas forcément besoin d'un type particulier : certains caches, les bindings, etc.

    Citation Envoyé par bountykiler Voir le message
    Pour ce qui est de void* (et non void ), son utilisation est à proscrire autant que possible.
    Le type est bien void L'équivalent Java de void* serait plutôt Reference<Void>.

    Citation Envoyé par bountykiler Voir le message
    Bof, perso quand je vois ce qu'il a écrit, j'ai quand même quelques doutes. En fait, j'ai un peu l'impression qu'il jette le bébé avec l'eau du bain. Tout n'est pas parfait en C++, mais quand on le compare avec le C, le C++ apporte quand même beaucoup de facilités je trouve. (le problème étant qu'il n'est pas toujours facile de toutes les maitriser).
    Quand j'ai débuté le C++, je voyais les classes comme des struct avec des pointeurs de fonction Par ailleurs, il y a un article sur comment faire des classes en C en utilisant des struct et quelques bidouilles sur les pointeurs.

    Citation Envoyé par bountykiler Voir le message
    Ben désolé mais moi j'en vois une!
    Si je veux par exemple utiliser un id (donc un int) afin de stocker différents éléments dans ma map, j'apprécie que mon compilo vérifie ce fait et me prévienne si jamais à un moment donné j'essaie d'y mettre autre chose qu'un entier.
    Après, il est possible que l'on veuille pouvoir utiliser n'importe quoi comme clé dans un cas précis, mais si je sais à l'avance que je n'y pettrai que des entiers, je préfère que mon compilo le vérifie.
    Si c'est ce que tu veux, il le fera. Mais dans le même ordre d'idée, il n'ira pas vérifier que l'id existe ou à un sens ... Ou même correspond bien à l'objet auquel tu l'associes.

    Citation Envoyé par adiGuba Voir le message
    D'après ce que je lit sur wikipedia, ces méthodes final sont non-virtuelle. Donc cela ne pose aucun problème même avec l'héritage multiple.
    Ca ne change rien. Comment tu gères deux méthodes concrètes qui ont la même signature ?

    Citation Envoyé par adiGuba Voir le message
    En C++ toute les méthodes sont non-virtuelle par défaut, et il faut explicitement les marquer comme tel pour qu'elle le deviennent. Cela limite bien les problèmes de l'héritage multiple, car si la méthode parente n'est pas virtuelle on peut utiliser le même nom de méthode sans que cela ne pose de conflit.
    Dans le cadre de méthode non-virtuelle, c'est le type du pointeur qui permet de déterminer la méthode à exécuter ?

    En Java, mis à part les méthodes private, toutes les méthodes d'instances sont virtuelles. En Java le mot clef final sert juste à interdire la redéfinition de la méthode (qui reste quand même virtuelle).
    Donc en cas d'héritage multiple le risque de conflit est très élevé !

    Citation Envoyé par adiGuba Voir le message
    A noter que Java 8 apportera un nouveau concept qui permettra de simuler l'héritage multiple (même si ce n'est pas son objectif initial), via les "Default Methods".

    Le premier objectifs des "Default Methods" est de permettre l'évolution des interfaces existantes en y ajoutant des méthodes avec un code par défaut qui sera utilisé uniquement dans le cas où la classe n'implémente pas la méthode.

    Bref : on pourrait mettre du code dans une interface.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    public interface Iterable<T> {
    	
        public Iterator<T> iterator();
        
        public boolean isEmpty() default {
        	return !iterator().hasNext();
        }
    }

    Au niveau de la résolution c'est beaucoup plus simple car la moindre implémentation dans une classe de la hiérarchie prendra obligatoirement le pas sur la méthode par défaut de l'interface.
    Quelle différence avec l'héritage multiple ? On pourrait appeler le code par défaut si besoin ?
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  9. #1829
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    Août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : Août 2005
    Messages : 2 894
    Points : 7 083
    Points
    7 083
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    a- En interne, il y a 150 façons différentes de réaliser ces points de variations (dans le makefile (ou assimilé) au niveau du choix du .cpp compilé, par préprocesseur, ou autre, peu importe).
    C'est en interne des libs tierces. Dans le code métier que nous développons nous, il n'y a rien de tout ça.
    Il y a aujourd'hui extrêmement peu de raisons pour tester la plateforme dans les codes que l'on tape quotidiennement.
    Comme je l'ai répondu, c'est surtout pour revenir sur la critique de Java a besoin d'une VM ... Comme tout le monde, il faut bien abstraire le plateforme.

    Citation Envoyé par Luc Hermitte Voir le message
    b- les libs tierces on ne les compile qu'une (série de) fois par plateforme ... quand elles ne viennent pas déjà précompilées.
    Où est le soucis ?
    Dans le monde dans lequel je travaille, on part de ce qui est distribué. Ce qui revient à compiler assez souvent.
    Ensuite je ne sais pas quelle part de bibliothèque dynamique ou statique représente les bibliothèques en C++, ou alors on peut conserver les .o ?
    J'avoue que les chaînes et unité de compilation du C++ sont bien loin !

    Citation Envoyé par Luc Hermitte Voir le message
    c- Le peu que j'ai vu de ruby, j'ai beaucoup aimé son approche quant à la séparation héritage orienté substituabilité et import de code.

    Après Java supporte l'héritage multiple et virtuel (mais limité aux interfaces). D'où que n'étant pas capable d'étendre aux comportements, il ne permet pas de supporter la programmation par contrat de façon native avec des contournements façon pattern NVI. (il repose à la place sur une phase de précompilation)
    En Java tu peux très bien remplacé les NVI par de la programmation par aspect. Ce qui est de la post-compilation. La post-compilation est bien prévue par Java mais pas nécessairement pour faire de la programmation par contrat ou NVI.

    Citation Envoyé par Luc Hermitte Voir le message
    e- Le concept de fonction trigo ne représente rien. sin et cos ne présentent pas le grand intérêt à être interchangeables.
    Pire instancier cos pour faire le calcul ? Mais voilà un bien étrange idée. Je vois bien le
    Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    Cos cos = new Cos();
    double l = cos.compute(pi) * 42;
    Franchement ? Non.
    Dit comme ça oui, sauf que Cos est un singleton. Il n'en existe qu'une seule instance dans un monde donné (ou une instance d'un monde, si on émet l'hypothèse du multivers ^^).
    Il est difficile de représenter les singletons sans méthode static mais cela reviendrait à créer une instance de Monde au début du programme et que Monde (ou l'une de ses propriétés) soit passé en paramètre à chaque objet construit.
    Franchement, non ?

    Citation Envoyé par Luc Hermitte Voir le message
    f- Dans bien des cas, cela va couter autant de binaire que si on avait fait la même chose à la main (typiquement avec chaines et vecteurs qui sont des surcouches très light au dessus des tableaux C).
    Template ou générique, c'est codé une fois.

    Citation Envoyé par Luc Hermitte Voir le message
    g- mais mes listes sont toujours spécifiques.
    Tu ne me verras jamais avoir des listes de carottes et voitures. (même si std::list<boost::any> me le permettrait)
    Et pour les légumes, j'ai des std::list<legumes*> (/boost::ptr_list<legume>/std::list<std::unique_ptr<legume>>/...).
    Et si j'ai besoin de faire des recherches ben ... je n'ai aucun downcasting à réaliser depuis le type Object car le légume exposera le critère sur lequel je réalise ma recherche.
    Si on oublie l'héritage du C relativement aux types primitifs et void*, le typage du C++ induit par les templates est supérieur à celui du Java (pre Generics) -- fichu C!
    Dans ta liste de voiture, tu peux avoir des 4x4, des picks-up, des berlines, des citadines, idem pour les légumes.
    Donc tu as tout de même supposé avoir un minimum. Si je suppose que mon minimum c'est Object parce que je n'ai pas de point commun en terme de relation structurelle, où est le problème ?
    Si tu prends le cas, si je veux faire n'importe quoi, je peux faire n'importe quoi et il arrive n'importe quoi ; je peux pas te contredire, c'est bien vrai. Mais je pense que pourrais faire encore plus n'importe quoi en C++.

    Citation Envoyé par Luc Hermitte Voir le message
    h- Parce que ce n'est pas trivial et qu'il y avait eu des soucis à mélanger tous les ajouts du langages concepts, lambda, etc.
    Je parlais du void* ou superobject.

    Citation Envoyé par Luc Hermitte Voir le message
    i- Certainement pas. Je me retrouve avec des templates et un typage très précis sans la moindre racine mémorielle commune (void*).
    Regarde le C (et peut-être même java). Il n'y a pas besoin de void* pour ajouter un int à un double. Ben les templates, c'est pareil.
    int et double ne sont pas des classes.
    Et je parlais de mélanger deux objets de frameworks différents qui n'auraient pas eu l'idée d'utiliser un type commun mêmes si les signatures sont sensables.
    Après comme vous l'évoquiez, on peut wrapper/adapter/bridger. Mais je me vois mal annoncer à mon client : "bon il vous en coûtera 25% de plus parce qu'on veut que conceptuellement ce soit bien fait".
    Surtout qu'à l'heure d'aujourd'hui la facturation tend à être forfaitisé sur un catalogue de service.
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  10. #1830
    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 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Nemek Voir le message
    Ca ne change rien. Comment tu gères deux méthodes concrètes qui ont la même signature ?
    Si les méthodes ne sont pas virtuelles, alors il n'y a pas de redéfinition de méthode même si elles ont le même nom et la même signature. Le compilateur se contente de générer un appel de méthode "statique" selon le type déclarée de la variable à la compilation.


    Citation Envoyé par Nemek Voir le message
    Dans le cadre de méthode non-virtuelle, c'est le type du pointeur qui permet de déterminer la méthode à exécuter ?
    Dans tous les cas, la méthode à appeler sera déterminé à la compilation selon le type déclaré de la variable.

    La différence vient ensuite selon le type de méthode :
    • Pour une méthode non-virtuelle, cela génèrera un appel de méthode statique, c'est à dire que ce sera cette même méthode qui sera exécuté quel que soit le type réel de l'instance.
    • Pour une méthode virtuelle, cela génèrera un appel de méthode dynamique, c'est à dire qu'on recherchera la méthode a exécuté selon le type réel de l'instance à l'exécution.


    Exemple (si mon C++ n'est pas trop rouillé) :
    Code C++ : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    class Parent {
    public:
    	void method() {
    		std::cout << "Parent::method()\n";
    	}
     
    	virtual void virtualMethod() {
    		std::cout << "Parent::virtualMethod()\n";
    	}
    }
     
     
    class Child : public Parent {
    public:
    	void method() {
    		std::cout << "Child::method()\n";
    	}
     
    	virtual void virtualMethod() {
    		std::cout << "Child::virtualMethod()\n";
    	}
    }
     
     
     
    Parent parent = new Parent();
    parent.method();	// Parent::method()
    parent.virtualMethod();	// Parent::virtualMethod()
     
    Child child = new Child();
    child.method();		// Child::method()
    child.virtualMethod();	// Child::virtualMethod()
     
    Parent cp = new Child();
    cp.method();		// Parent::method()
    cp.virtualMethod();	// Child::virtualMethod()


    Donc les méthodes non-virtuelles ne posent aucun soucis avec l'héritage multiple puisqu'elles sont vues comme des méthodes différentes même si elles ont le même nom/signature.


    Comme en C++ les méthodes sont non-virtuelles par défaut cela limite la casse avec l'héritage multiple.
    En Java vu que tout est virtuelle par défaut tu serait rapidement plus embêté par cela.


    Citation Envoyé par Nemek Voir le message
    Quelle différence avec l'héritage multiple ? On pourrait appeler le code par défaut si besoin ?
    La différence vient des règles de résolution de méthode, avec des redéfinitions de méthodes simplifiés. Ces "Default Methods" ne peuvent pas prendre le pas sur une méthode définie dans une classe parent.

    A partir du moment où il existe une vrai implémentation de la méthode (dans le code de la classe ou d'une de ses classes parentes), cette implémentation est prioritaire sur n'importe quels "default methods" de n'importe quelle interface...


    En clair on ne se tourne vers les "default methods" uniquement lorsque la méthode n'est pas implémentées dans la hierarchie de la classe. En gros si la méthode n'est JAMAIS implémenté par la classe ni aucune de ses classes parentes.


    Tu ne peux donc avoir un conflit QUE pour une méthode avec deux "default methods" provenant de deux interfaces distinctes que tu implémentes. Et dans ce cas là on t'oblige à implémenter la méthode définie dans l'interface (ce que tu dois obligatoirement faire actuellement).



    Tu peux faire quelque chose d'assez proche de l'héritage multiple, tout en conservant une hiérarchie "propre".


    a++

  11. #1831
    Membre chevronné

    Homme Profil pro
    Architecte logiciel
    Inscrit en
    Novembre 2006
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte logiciel
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1 252
    Points : 1 954
    Points
    1 954
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    e- Le concept de fonction trigo ne représente rien. sin et cos ne présentent pas le grand intérêt à être interchangeables.
    Pire instancier cos pour faire le calcul ? Mais voilà un bien étrange idée. Je vois bien le
    Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    Cos cos = new Cos();
    double l = cos.compute(pi) * 42;
    Franchement ? Non.
    Plus simple:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
      double l = Cos.instance.compute(pi) * 42
    Des fonctions dans des objets ça s'appelle des foncteurs, et ça a son utilité.

  12. #1832
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    Août 2005
    Messages
    2 894
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : Août 2005
    Messages : 2 894
    Points : 7 083
    Points
    7 083
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    ...
    Merci pour les précisions
    Faudrait que écrives un article sur Java7 Et éventuellement Java8, s'ils ont figé la JSR mais je crois pas ?

    J'avais un peu zappé cette histoire de virtuel/non-virtuel et je voulais coller les NVI à Java C'est impossible même avec les default methods :/
    Ce qui serait bien c'est d'avoir les deux : héritage multiple avec des méthodes uniquement final et/ou abstraites ou les default methods.

    Sinon autorisé l'héritage multiple mais générer une erreur de compilation en cas de conflit, et comme pour les default methods, obliger à rédéfinir la méthode. Mais c'est ce que fait C++ (non ?)

    Question purement syntaxe C++, new génère un pointeur ou une valeur ?
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  13. #1833
    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 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Nemek Voir le message
    Faudrait que écrives un article sur Java7
    C'est en cours mais je manque de temps


    Citation Envoyé par Nemek Voir le message
    Sinon autorisé l'héritage multiple mais générer une erreur de compilation en cas de conflit, et comme pour les default methods, obliger à rédéfinir la méthode. Mais c'est ce que fait C++ (non ?)
    C'est possible mais cela pourrait engendrer beaucoup plus de cas de conflit qu'en C++ du fait que toutes les méthodes sont virtuelles. C'est ce choix du tout virtuel qui a du faire pencher la balance sur l'interdiction de l'héritage multiple.


    De toute manière l'objectif des "default methods" ce n'est pas vraiment l'héritage multiple. Son objectif principal est de permettre l'évolution des interfaces en y ajoutant des méthodes sans "tout casser"...


    a++

  14. #1834
    Rédacteur/Modérateur

    Avatar de gorgonite
    Homme Profil pro
    Ingénieur d'études
    Inscrit en
    Décembre 2005
    Messages
    10 322
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur d'études
    Secteur : Transports

    Informations forums :
    Inscription : Décembre 2005
    Messages : 10 322
    Points : 18 679
    Points
    18 679
    Par défaut
    Citation Envoyé par Nemek Voir le message
    Question purement syntaxe C++, new génère un pointeur ou une valeur ?
    un pointeur
    Evitez les MP pour les questions techniques... il y a des forums
    Contributions sur DVP : Mes Tutos | Mon Blog

  15. #1835
    Membre actif
    Avatar de EtherOS
    Homme Profil pro
    Etudiant Polytechnicien
    Inscrit en
    Juillet 2012
    Messages
    58
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Etudiant Polytechnicien
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2012
    Messages : 58
    Points : 233
    Points
    233
    Par défaut C++ against Java
    Sujet :<<C++ vs Java>>

    --> C/C++

    le Langage C/C++ est facile a utiliser ,plus comprehensible et vraiment efficace.Il est un langage de base et de haut niveau pour les reseaux,la securite et le developpement .De plus, lorsqu'on regarde par exemple le Framework Qt x.xx x <=10 du C++, on voit les capacites du C++ encor plus clair avec l'impact dans tous les domaines satellites, mobiles, reseaux, jeux 3D,2D et Web , beaucoup d'autres choses interessantes.

    --> Java (EE,FX,etc...)
    Celui-ci est plus portable, evolue et efficace dans le developpement d'applications mobile, satellite, commande des voitures , serveurs ,GPS, bref logiciels de haut niveau . De plus , tres bon dans la programmation reseau et Web.
    Bref le Java reste toujours le plus utilise pour des projets de haut niveau , Hi-TECH

    Excusez moi pour la redaction orthographique mal faite (pb de mon ordinateur)

    Merci

  16. #1836
    Futur Membre du Club
    Homme Profil pro
    Collégien
    Inscrit en
    Septembre 2012
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 27
    Localisation : Belgique

    Informations professionnelles :
    Activité : Collégien

    Informations forums :
    Inscription : Septembre 2012
    Messages : 1
    Points : 6
    Points
    6
    Par défaut
    EtherOS, personnellement, je ne suis pas d'accord, je trouve que le langage C++ est vraiment un langage drastiquement complexe à apprendre notamment à toutes les possibilités qu'on lui à découvert en détournant d'autres de ces possibilités. Ceci dit, je ne critique pas ce qu'il est possible de faire avec C++.

  17. #1837
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2003
    Messages
    5 275
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Août 2003
    Messages : 5 275
    Points : 10 985
    Points
    10 985
    Par défaut
    -1 pour "C/C++".
    Le C++ est déjà assez compliqué à lui tout seul, quand on l'utilise en mode "C with classes", c'est une catastrophe à maintenir. C et C++ sont deux langages à part entière, chacun avec ses bonnes pratiques (la faute aux exceptions). Et ça, c'est le sujet d'un autre troll planqué dans le forum C ou celui C++, je ne sais plus.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  18. #1838
    Membre expert Avatar de jabbounet
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Juin 2009
    Messages
    1 909
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48

    Informations professionnelles :
    Activité : Consultant informatique

    Informations forums :
    Inscription : Juin 2009
    Messages : 1 909
    Points : 3 284
    Points
    3 284
    Par défaut
    Citation Envoyé par EtherOS Voir le message
    Sujet :<<C++ vs Java>>

    --> Java (EE,FX,etc...)
    Celui-ci est plus portable

    Merci
    Dans la limite ou un jvm existe sur la plateforme pour laquelle tu souhaite faire ton soft....
    Ce qui nécessite souvent un compilateur C pour que la jvm puissent déjà y etre portée elle même.
    bazar: http://www.improetcompagnie.com/publ...ctacles-6.html

    BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil

    Emacs Wiki: http://www.emacswiki.org/

    En attente de ce que produira: http://www.pushmid.com

  19. #1839
    Membre averti
    Homme Profil pro
    Directeur de projet
    Inscrit en
    Octobre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Directeur de projet

    Informations forums :
    Inscription : Octobre 2012
    Messages : 117
    Points : 343
    Points
    343
    Par défaut
    J'avoue méconnaitre le C++, a peu près 10 ans de C et 10 ans de Java, je n'ai jamais réussi a me faire au C++, déjà dès son arrivée et encore moins après m'être essayé a Java, Python ... Je trouve que le C++ est le pire langage que l'on puisse imaginer pour faire comprendre l'objet car il ne va pas "a l'essentiel".

    Maintenant, selon le domaine d'application, on a guère le choix on prendra ou le C++, ou Java (ou un autre langage encore ...), faire du "système" en Java serait une hérésie comme faire du web en C++ du temps perdu, par contre la question peut se poser entre les deux où ils pourraient être "en compétition".

    Toutefois, même si la technologie ne vaut que parce que l'on en fait, il est une sorte de "philosophie" d'un langage qui va influer sur les habitudes que l'on prend en l'utilisant. De son origine, destiné a permettre le contrôle d'une multitude d'équipements, la notion de "contrat" (interface) est prépondérante en Java et largement utilisée, elle est bien entendu possible en C++ mais moins "naturellement" mise en oeuvre. Dans une relation client/fournisseur entre deux modules de code, Java pousse a s'intéresser a ce dont le client a besoin, pas tout ce que le fournisseur peut fournir.

    On parle de portabilité et non plus de compatibilité (s'amuser a comparer l'approche de Sun de l'époque avec celle de Microsoft :-)) Je n'ai pas a "porter" un programme Java puisqu'il est conçu d'origine pour l'être et invite le développeur a le généraliser dans son architecture.

  20. #1840
    Rédacteur/Modérateur


    Homme Profil pro
    Network game programmer
    Inscrit en
    Juin 2010
    Messages
    7 113
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Canada

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : Juin 2010
    Messages : 7 113
    Points : 32 951
    Points
    32 951
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par rimram31 Voir le message
    la notion de "contrat" (interface) est prépondérante en Java et largement utilisée, elle est bien entendu possible en C++ mais moins "naturellement" mise en oeuvre. Dans une relation client/fournisseur entre deux modules de code, Java pousse a s'intéresser a ce dont le client a besoin, pas tout ce que le fournisseur peut fournir.
    Euh... pardon ?
    Quand tu passes en C++ tu débranches une partie de cerveau ?
    En quoi JAVA pousserait plus à l'utilisation d'interface que C++ ?
    Pensez à consulter la FAQ ou les cours et tutoriels de la section C++.
    Un peu de programmation réseau ?
    Aucune aide via MP ne sera dispensée. Merci d'utiliser les forums prévus à cet effet.

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, 17h15
  2. [Débat] .NET vs JAVA/J2EE
    Par tssi555 dans le forum VB.NET
    Réponses: 5
    Dernier message: 10/12/2008, 08h54

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