[Débat] C++ vs Java

Version imprimable

Voir 40 message(s) de cette discussion en une page

03/09/2007, 10h49
nicØB

Citation:

Envoyé par 5:35pm

Et si ca peut te rassurer, en Java ce ne sera pas possible (toute classe derivant de "object")

N'importe quoi. Pourquoi ça ne serait pas possible ? Qu'est ce qui empêcherait les développeurs de Java de le faire ?

Citation:

Envoyé par 5:35pm

Du point de vue d'un Cplusplusien; programmer avec Java, c'est simple. Mais faut pas le prendre mal, c'est une bonne chose nan?

Je suis ravis de t'entendre le dire, tu pourras donc m'aider quand j'aurais des questions pour un serveur avec clustering et tout le bazard. Developpez.com regorge de génies, c'est chouette. :mrgreen:

Citation:

Envoyé par 5:35pm

Je sais que tout ce qu'on dit la a deja ete dis, mais c'est tellment marrant de taper sur java :aie:

Le plus marrant c'est de te voir taper sur Java vu les âneries que tu sors. :aie:
03/09/2007, 10h58
5:35pm

Citation:

Si tu lisais ce qu'on écrivait, notamment adiGuba

oui, j'ai vu GPL, j'ai pas cherche plus loin.

Citation:

N'importe quoi. Pourquoi ça ne serait pas possible ? Qu'est ce qui empêcherait les développeurs de Java de le faire ?

la meme chose qui a empeche microsoft de l'implementer dans C#.
avec l'heritage multiple, on doit eviter les ambiguite, et par exemple, comme toute class a une methode ToString(), il y a ambiguite.

bon en tout cas, Java open source, j'avoue ca remonte bien l'estime de ce language =)
la chez moi c'est deux heures du mat, je vous laisse.
03/09/2007, 11h07
adiGuba

Citation:

Envoyé par 5:35pm

alors je suis reste sur cette phrase un bon moment. Qu'elle est le rapport entre l'heritage multiple et les methodes virtuelles? j'ai beau chercher, je vois pas, c'est normal n'y en a pas. les limitations de l'heritage multiple ce situent lorsqu'il y a des ambiguites; par exemple quand deux classes ont la meme methode.

C'est simplement que comme les méthodes sont virtuelles, il y a plus de chance d'avoir des ambigüités...

Citation:

Envoyé par 5:35pm

donc je pourrais tres bien aimer Java pour ca; et comme je l'ai dis, pourquoi le prendre mal?

Je ne le prend pas mal ;)
Mais si le langage est effectivement simple (par rapport au C++), il n'en demeure pas qu'il existe des spécificités et des concepts à connaitre...
C'est trop réducteur de croire qu'en maitrisant le C++ on maitrise Java car "c'est plus simple" !

Citation:

Envoyé par 5:35pm

ca veut dire que Java n'est plus proprietaire, c'est un standard, comme c++.
les specifications de Java sont disponible, mais pas l'implementation.

Cela a toujours été le cas : les spécifications de Java ont toujours été disponible et d'ailleurs l'évolution même du langage et de ses APIs sont soumis aux votes des membres du Java Community Process, dans lequel on retrouve un grand nombre d'entreprise ou de particulier...

Le passage en opensource ne concerne que l'implémentation officielle de référence, c'est à dire la JVM de Sun.

Des implémentations d'autres JVM existe depuis longtemps, que ce soit chez IBM, Apple, ou encore Excelsior.

Seul le nom "Java" est réservé et ne peut être utilisé qu'après avoir passé un test de compatibilité (TCK).

D'ailleurs il existait également plusieurs JVM opensource, que ce soit SableVM, Kaffe ou GCJ (qui permet d'ailleurs une compilation en natif).

Mais le problème de ces JVM venait des APIs de Java, assez conséquente et dont la réécriture représente un travail énorme (qui a malgré tout été lancé par les projet GNU Classpath et Harmony).

a++
03/09/2007, 11h14
Kujara

Citation:

Envoyé par super_navide

Après générer du code avec le préprocesseur/compilateur via les templates
a un intéret discutable.

Mon dieu, ce qu'il faut pas entendre >.<

2 mots :

STL

BOOST
03/09/2007, 12h26
pseudocode

Houla... on voit que c'est lundi. Une page en une matinée...

Concernant Java et la GPL, je pense que l'objectif de SUN est d'aider a l'adoption de Java comme langage de prédilection sur Linux/BSD (afin de resister au couple windows/c#). Bon, le problème c'est que la communauté Linux/BSD est plutot adepte du C/C++ et ca m'etonnerai qu'ils accueillent Java a bras ouverts. :?

J'ai vu passer aussi une remarque sur la GPL du genre "Java sous GPL => application sous GPL". Arg! Quand je pense au nombre de programmes complilés avec gcc et vendus une petite fortune....

Pour la question "est-ce que les templates C++ peuvent faire aussi bien que les generics Java?"... Mouarf. Les templates sont ENORMEMENT plus puissants que les generics. Et donc enormement plus complexes: on n'a rien sans rien.

L'obsolescence du C++ n'est pas pour toute suite. Des lors qu'on veut un langage OO et qu'on a des contraintes de performance (vitesse, memoire, footprint, ...), on peut eliminer tous les langages basés sur une VM ou sur le GC. Par contre, si on veut portabilité et sécurité (au sens "limiter les degats potentiels") utiliser une VM peut etre un bon choix (cf JME sur les telephones portables).

Et pour finir, l'heritage multiple n'est pas "techniquement" impossible en Java (d'ailleurs il existe en C#). Pour lever les ambiguités, il suffirait de faire preceder le nom de la methode par le namespace, comme c'est le cas actuellement pour des classes homonymes issues de packages differents. L'heritage multiple a été interdit en Java pour des raisons conceptuelles, et non techniques. ;)
03/09/2007, 13h00
koala01
Et concernant l'héritage multiple, avec la possibilité d'avoir un héritage virtuel, il n'y a même pas la limitation du "tout descend d'une même classe" car, bien que ce ne soit pas recommandable dans tous les cas, un code du genre de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 class base { /*...*/ }; class B1:virtual public Base { /*...*/ }; class B2:virtual public Base { /*...*/ }; class Derivee:public B1, public B2 { /*...*/ };
est tout à fait légal en C++...

Au niveau de l'utilisation des template, on peut citer tout ce qui à trait à la spécialisation partielle et/ou totale, à la création de traits ou de polices qui permet d'avoir un vérification, lors la compilation même du bon usage du template utilisé...
03/09/2007, 13h50
HanLee
Citation:
Envoyé par koala01

Et concernant l'héritage multiple, avec la possibilité d'avoir un héritage virtuel, il n'y a même pas la limitation du "tout descend d'une même classe" car, bien que ce ne soit pas recommandable dans tous les cas, un code du genre de

Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 class base { /*...*/ }; class B1:virtual public Base { /*...*/ }; class B2:virtual public Base { /*...*/ }; class Derivee:public B1, public B2 { /*...*/ };

est tout à fait légal en C++...

Au niveau de l'utilisation des template, on peut citer tout ce qui à trait à la spécialisation partielle et/ou totale, à la création de traits ou de polices qui permet d'avoir un vérification, lors la compilation même du bon usage du template utilisé...
policy -> politique et pas police :aie: !
03/09/2007, 14h58
adiGuba

Citation:

Envoyé par pseudocode

J'ai vu passer aussi une remarque sur la GPL du genre "Java sous GPL => application sous GPL". Arg! Quand je pense au nombre de programmes complilés avec gcc et vendus une petite fortune....

Comme je l'ai dit plus haut, la licence comprend une Classpath-Exception qui n'a aucun impact sur la licences des applications développées en Java ou qui nécessitent une JVM...

Citation:

Envoyé par pseudocode

Pour la question "est-ce que les templates C++ peuvent faire aussi bien que les generics Java?"... Mouarf. Les templates sont ENORMEMENT plus puissants que les generics. Et donc enormement plus complexes: on n'a rien sans rien.

Je ne sais pas si les templates sont plus puissant... mais ce qui est sûr c'est qu'ils ont une approche très différentes ;)

J'en ai déjà parlé sur mon blog (un peu de pub :aie:) : Les Generics ne sont pas des Templates comme les autres !

a++
03/09/2007, 15h13
super_navide

--------------------------------------------------------------------------------

Les générics de java on l'avantage d'être contenu dans le fichier .class générer à la compilation.

Alors qu'en C++ il faut précompiler les headers .

A moins que maintenant on peut tout mettre dans les fichiers .obj

une autre chose que je trouve nulle en C++ ce sont les headers c'est lourds je trouve a gérer.
en java on écrit un seul type de fichier le fichier .java .

Je vois que personne n'a répondu pour l'implémentation d'un proxy en c++ comme en Java

un Proxy en java permet d'implémenter dynamiquement une interface

par example
interface Personne {
String nom();
String prenom (); }

on peut créer un objet proxy (sans créer explicitement de classe ) qui implemente l'interface
et chaque appel à un méthode de l'interface provoque l'execution d'une méthode
Object invoke(Object reiceiver,Method m,Object [] arguments)

cet mecanisme permet de faire bcp de chose par exemple tracer tous les appel fait a un objet
03/09/2007, 16h30
pseudocode

Citation:

Envoyé par super_navide

Je vois que personne n'a répondu pour l'implémentation d'un proxy en c++ comme en Java

<hors sujet>
Hum... il m'a l'air louche ton DP Proxy. Je ne vois pas trop a quoi sert l'invocation dynamique des methodes. Pourquoi ne pas appeler directement les methodes de ton objet Receiver ? C'est parceque tu ne connais pas son interface, ou c'est pour etre extensible ?
</hors sujet>

Citation:

Envoyé par pseudocode

<hors sujet>
Hum... il m'a l'air louche ton DP Proxy. Je ne vois pas trop a quoi sert l'invocation dynamique des methodes. Pourquoi ne pas appeler directement les methodes de ton objet Receiver ? C'est parceque tu ne connais pas son interface, ou c'est pour etre extensible ?
</hors sujet>

<hors sujet mais c'est intérressant>

La classe Proxy appartient à l'API de réflection, et permet de générer des implémentation générique. Un des meilleurs exemple que je connaisse vient de l'API EoD SQL dont j'ai déjà parlé.

Grosso-modo cela permet de faire des mapping Object-SQL très facilement, comme le montre cet exemple :
http://eodsql.sourceforge.net/about.html#example
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 // The Query interface public interface UserQueries extends BaseQuery { @Select("SELECT * FROM users WHERE password = ?1") public DataSet<User> getUsersByPassword(String password); @Select("SELECT * FROM users WHERE id = ?1") public User getUserbyId(Integer id); // Declaring SQLExceptions is entirely optional.If you don't declare them // in a throws clause, they'll be wrapped in a RuntimeException for you. @Update("UPDATE users SET username = ?{1.username}, " + "password = ?{1.password}, birth_date = ?{1.birthDate} WHERE id = ?{1.id}") public int updateUser(User user) throws SQLException; }
Le code des méthode de ces interfaces est générique, puisqu'il suffit d'exécuter le code SQL contenu dans l'annotation, et de mapper le résultat vers les objets en retour. Il est ainsi possible de faire une méthode unique et le proxy permet donc de renvoyer les appel vers une méthode invoke() qui comportement tout les traitements.

Grosso-modo à l'utilisation on fait ceci :

Code:

UserQueries userQueries = QueryTool.getQuery(UserQueries.class);

Et on obtient un implémentation de l'interface UserQueries sans avoir taper le moindre code ;)

a++

03/09/2007, 16h47
super_navide

Avec ce mecanisme de proxy tu peut implementer une lecture automatique dans fichier XML

par exemple
interface Personne {
String nom( ) ;
String prenom( ) ;
}

peut être lier au une chaine XML
<Personne>
<nom>Durant</nom>
<prenom>Pierre</prenom>
<Personne>

ou a une classe
class PersonneImpl implements Personne {
String nom() { return "Durant"; }
String prenom() { return "Pierre"; } }

Cela permet de faire par exemple un configuration par défaut avec une classe et une autre avec un fichier XML ou une Base de données etc ..

Et la C++ il dit quoi hein hein....
03/09/2007, 17h03
pseudocode

@adiGuba & super_navide: visiblement vous parlez pas de la meme chose: java.lang.reflect.Proxy / Design-Pattern Proxy (voir meme strategy).

Critères de comparaison, évolutions des langages, et fonctionnalités.

Pfiou, j'ai tenté de tout lire, mais il me semble que le débat aborde beaucoup trop de concept pour comparer les 2 langages:
Est-ce qu'on compare les fonctionnalités, les performances, la diffusion selon le type de plate-forme, la présence sur le marché: autant de de sujet de débat.

ce qui m'intéresserais en priorité:
-En tant que responsable de projet: c'est ce que je peux faire du langage, est-ce qu'il est plus adapté à ma problématique, et moins compliqué ou plus rapide à utiliser, donc moins cher au développement?
-En tant que développeur: quel sera le langage dans lequel l'emploi marchera le mieux dans mon domaine, et ne risque pas de s'obsolétiser comme ce fut le cas de Basic ou Pascal?

Pour ouvrir sur un autre point, ce qui nous intéresse dans ce débat, c'est peut-être:
"Est-ce qu'il est possible d'avoir un seul langage unifié, le C++ ou le Java, pour répondre à toutes les problématiques?"
Je pense qu'à l'heure actuelle faudrait pour que ce soit le cas soit faire évoluer l'un des langages, soit en créer un 3ème, mais je ne suis pas convaincu par le C# .

<La question du proxy>
le proxy est par exemple utile pour analyser le code à l'exécution, notamment faire du profiling. J'ignore si le profiling est possible en C++, mais ce qui est sur, c'est que le proxy dynamique utilise l'invocation d'une méthode par son nom, ce que est de la pure réflecivité, et est donc impossible en C++.
il doit être en revanche possible de générer une classe de proxy avant la compilation, par un compilateur had-hoc.
edit: le mapping de données est également intéressant ;) mais pourrais être obtenu également par génération de code avant compilation.

La réflexivité n'est qu'une des fonctionnalités qui diffère entre Java et C++
On pourrait se demander lesquelles sont indispensables:
Code:

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.

04/09/2007, 01h26
5:35pm

Citation:

Envoyé par pseudocode

Et pour finir, l'heritage multiple n'est pas "techniquement" impossible en Java (d'ailleurs il existe en C#). Pour lever les ambiguités, il suffirait de faire preceder le nom de la methode par le namespace, comme c'est le cas actuellement pour des classes homonymes issues de packages differents. L'heritage multiple a été interdit en Java pour des raisons conceptuelles, et non techniques. ;)

Non, l'heritage multiple n'existe pas en C#, on peut seulement ajouter des interface.
Je maintiens que Java ne l'implemente pas pour des raisons technique; car l'heritage multiple implique des precautions d'utilisation; conceptuellement parlant, ca apporte de grands avantages c'est indeniable.
04/09/2007, 01h43
LLB

Citation:

Envoyé par 5:35pm

Je maintiens que Java ne l'implemente pas pour des raisons technique; car l'heritage multiple implique des precautions d'utilisation; conceptuellement parlant, ca apporte de grands avantages c'est indeniable.

Oui, c'est la même philosophie que la surcharge d'opérateurs : c'est puissant, ça apporte des avantages, mais ça peut être dangereux quand c'est mal utilisé (il faut prendre des précautions).

C'est donc la philosophie de Sun qui est en cause ici. Si on ne l'aime, peut-être vaudrait-il mieux se tourner vers le D ? (mais c'est un autre débat...)
04/09/2007, 12h08
pseudocode

Citation:

Envoyé par 5:35pm

Je maintiens que Java ne l'implemente pas pour des raisons technique; car l'heritage multiple implique des precautions d'utilisation; conceptuellement parlant, ca apporte de grands avantages c'est indeniable.

Oui, la MI (Multiple inheritance) n'est techniquement pas supportable par la JVM actuelle. Cependant, je suis sur qu'il y a des gens assez competent chez Sun pour faire les modifications techniques necessaires. De plus, il existe des JVM modifiées (non officielles) qui permettent la MI.

"conceptuellement parlant", ca apporte effectivement de grands avantages, mais egalement le grand risque de tomber dans le piege du "Diamond of Death".
04/09/2007, 13h23
Kujara

Citation:

Envoyé par pseudocode

"conceptuellement parlant", ca apporte effectivement de grands avantages, mais egalement le grand risque de tomber dans le piege du "Diamond of Death".

Comme le c++ arrive a gerer le diamond of death avec l'heritage virtuel, Java devrait y arriver aussi, si un jour ils s'il mettent ^^.
04/09/2007, 13h46
koala01

Citation:

Envoyé par pseudocode

Oui, la MI (Multiple inheritance) n'est techniquement pas supportable par la JVM actuelle. Cependant, je suis sur qu'il y a des gens assez competent chez Sun pour faire les modifications techniques necessaires. De plus, il existe des JVM modifiées (non officielles) qui permettent la MI.

"conceptuellement parlant", ca apporte effectivement de grands avantages, mais egalement le grand risque de tomber dans le piege du "Diamond of Death".

Comme je l'ai indiqué plus haut, avec la notion d'héritage "virtuel", il n'y a aucun problème... à condition de réfléchir correctement à ce qu'on fait, et à la manière de concevoir les différentes classes ;)

Comme je l'ai signalé, certains déconseillent d'avoir recours à cette technique, justement, parce qu'il est facile de tomber dans le "grand n'importe quoi", mais il y a facilement moyen de faire quelque chose d'excellent avec ;)
04/09/2007, 13h51
adiGuba

Citation:

Envoyé par Kujara

Comme le c++ arrive a gerer le diamond of death avec l'heritage virtuel, Java devrait y arriver aussi, si un jour ils s'il mettent ^^.

Comme je l'ai dit la différence est surtout qu'en Java tout est virtuel par défaut à l'inverse du C++...

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 :

Citation:

There are no plans to extend Java with multiple inheritance. Multiple implementation inheritance is sometimes a convenience, but it is
never essential.

a++

Voir 40 message(s) de cette discussion en une page