On dit aussi que la democratie, c'est la dictature de la majorite sur la minorite ...
La quantite etant rarement synonyme de qualite, la democratie "betifie" la nation.
Bon, c'est un avis perso, je ne connais pas de meilleur systeme que la democratie, c'est donc le moins pire.
La proposition de Yeupou a sa place ici, car il s'agit d'un lieu de discussion. Bref, contrairement a la dictature, on peut donner son avis, et partir de la pour discuter, et eventuellement tomber d'accord.
Discuter c'est aussi parler a deux et argumenter. Aussi je trouve ton commentaire assez deplace : tu parles de dictature mais n'apporte rien a la discussion ...
Bel exemple ma foi.
Pas tout a fait d'accord : en C++ tu peux faire du multi heritage avec des classes contenant des champs et donc te retrouver avec une classe qui contient des attributs differents possedant le meme nom :
Ex :
class A {int i}
class B : public A {}
class C : public A {}
class D : public B, C {}
D possede B::i et C::i ==> Super chiant.
On peut regler le probleme d'un seul coup en important tout le namespace de B (si on veut utiliser tout ce qui vient de B) ==>
class D : public B, C {using namespace B;} Ce qui permet d'eviter de nommer a chaque fois le chemin que l'on veut prendre.
En Java ce probleme ne se pose pas car une interface par definition ne contient que des methodes. Si deux methodes provenant de deux interfaces differentes ont le meme nom, tu n'as qu'une implementation (il y a des avantages et des inconvenients, c# a decide de permettre la resolution ==> On se retrouve avec deux methodes)
Bref, je suis pas d'accord avec ton terme d'heritage multiple, je parlerai plutot d'implementation multiple.
(Grosse difference entre C++ ou on "herite", et java ou on peut "etendre" et "implementer")
L'heritage multiple, c une facilite d'un langage qui permet a un programmeur de faire heriter une classe de plusieurs autres classes (grosso modo).
Des problemes se posent lors d'heritage en diamant par ex :
A
/ \
B C
\ /
D
D se retrouve avec 2 copies des methodes et des attributs de A. (un en passant par B, un autre en passant par C).
La plupart des problemes lies a l'heritage multiple c'est lors de la generation de code C++.
Pour faire de l'objet en C, grosso modo ce qu'on fait, c inclure la structure de la classe de base dans la classe derivee. De cette maniere, puisque les offsets des attributs sont toujours les memes, on se pose pas de question.
Lorsque tu as un heritage en diamant, comment tu calcules les offsets pour acceder a tes attributs ? On s'en sort en faisant du padding (en mettant des espaces entre les donnees) et en gerant l'acces aux attributs grace a un tableau qui indique comment acceder a un attribut donne suivant le type, mais ca complique les choses, et surtout ca ralentit pas mal l'execution du programme. On a le meme genre de probleme avec les methodes.
Tout ca pour dire que l'heritage multiple ca peut servir, mais souvent on s'en sort beaucoup mieux en revoyant son arbre d'heritage pour enlever les heritages multiples : l'arbre en general devient plus clair (mais c'est bien sur), preuve en general d'une meilleure architecture.
Le polymorphisme, (plusieurs formes, y a des latinistes dans le coin ??) permet a un objet d'un type donne de se faire passer pour un autre objet, ce qui est hyper pratique.
Ex : Tu as un arbre d'heritage
Vehicule
| \
Voiture Camion
Ton code :
Vehicule myVehicule = new Voiture();
==> Tu fait passer ta Voiture pour un Vehicule (normal une voiture est un vehicule)
==> Du code ecrit pour un vehicule fonctionnera a la fois pour une voiture et pour un camion.
Mais lorsque tu "overloade" une methode, ca te permet de changer la methode que tu vas appeler de facon transparente.
Ex :
myVehicule.f()
Si myVehicule est une Voiture, ca va appeler la methode f de Voiture, si myVehicule est un Camion, ca va appeler la methode f de Camion, etc...
Bon, tout ca est assez succinct, si tu veux un bon bouquin (online) pour commencer a voir ce que c'est que l'OO, va voir http://www.ibiblio.org/pub/docs/books/eckel/(...) et recupere "Thinking in java".
Tous les langages orientes objet (OO) implementent le polymorphisme, et l'heritage simple. Certains implementent aussi l'heritage multiple (C++, autre ?) plus d'autres "features" (RTTI, genericite, Reflexion, polymorphisme de methode, exceptions, ...).
Non je ne pense pas.
Voila les genres d'optimisations que te laisse faire le C++ : inline, const, virtual, ref, ... Ce sont avant tout des optimisations de bas niveau. Des optimisations qui te font perdre du temps alors que le compilateur pourrait et devrait (comme KCC) les faire a ta place.
En Java, on ne te laisse pas le loisir de faire des optimisations de bas niveaux parce que la JVM devrait le faire a ta place (mais c'est vrai avec n'importe quel compilo optimisant)
En fait, le C++ est cense etre un langage objet. Qui dit objet dit haut niveau, qui dit haut niveau dit : on l'utilise pour se prendre la tete sur des problemes haut niveaux. Si j'ai envie de me prendre la tete sur des problemes plus bas niveaux, je vais prendre des langages plus bas niveaux : le C ou a l'extreme l'assembleur : j'utilise le langage adapte a mes objectifs et a mon probleme. Avec le C++ on te donne l'illusion de faire du haut niveau alors que tu dois quand meme te prendre la tete avec des problemes bas niveaux. En Java non. Oui je suis d'accord rien ne t'empeche de faire de l'assembleur en C++. Dans ces cas la personnellement je prefere prendre un assembleur que du C++.
Simple question de decoupage de probleme.
Absolument d'accord avec toi.
J'ajouterai juste que tu parles de quelqu'un qui s'y connait. Qui connait deja la plupart des pieges et qui sait s'en depatouiller. Bref, pas a la portee du premier venu. C'est pourquoi personnellement je prefere Java : le langage a justement ete cree (designe) de telle maniere qu'on ne puisse pas faire la plupart des erreurs qu'un debutant en C++ ferait.
De plus, Java incite a se concentrer sur l'algorithmique et non pas sur l'optimisation. Chose qu'on ne fait pas en c++, car comme tu dis en C++ on est conscient qu'un appel virtuel ca coute du temps, ... Mais il y a pire : si tu met ou il faut comme il faut des const tu permet au compilo de faire plus d'optimisations. Tu peux aussi declarer tout un tas de methodes inline pour encore plus optimiser ton code.
Ou je veux en venir ?? A ceci :
en C++ on perd trop de temps a penser son programme en tant qu'architecture + optimisation. Resultat au lieu de penser architecture propre, on degrade le cote architecture pour le cote optimisation, et a la fin on a un truc qui pourrait etre largement mieux d'un point de vue architecture.
Le point de vue de Java c'est : pensez architecture ! Les optimisations, c la JVM qui s'en charge. Ca ne doit pas etre votre probleme.
Bon, ca c'est la theorie. En pratique la JVM fait tourner ton programme nettement moins vite que ton compilo C++. Mais je trouve que ca va dans le bon sens. Et c'est ca qui compte. Car finalement le compilateur (ou la JVM) est l'entite la mieux place pour savoir ou mettre les optimisations.
Maintenant combien de temps ca prendra pour optimiser mieux que le programmeur ??
On arrive deja a pondre du code assembleur meilleur que le pekin qui s'y connait, je pense que cette etape viendra. Peut etre pas tout de suite mais elle viendra. Et en attendant, mieux vaut penser architecture propre, puis refaire une passe optimisation que l'inverse ... :-)
Non, c pas possible.
Ce qui est possible en C++, ce sont les nested class, pas les inner class.
Difference entre une nested et une inner :
l'inner class garde une sorte de pointeur vers la classe enclosing, ce qui fait qu'on peut se servir de l'inner classe comme d'un callback vers la classe enclosing. Classe qui aura acces a toutes les methodes et a tous les attributs de la classe enclosing.
Perso, je trouve qu'ils ont repris des constructions de langages tres c++ qui ne font pas l'unanimite :
* Le mot clef virtual : la plupart des gurus objet expliquent que le but de l'objet est de faire de l'objet !! C'est a dire utiliser du polymorphisme : toutes les methodes devraient etre polymorphique par defaut : ca evite des bugs. Quand on donne a une methode le nom d'une methode de la classe mere, c'est qu'on veut l'overloader !
* Les references : Il y a un truc que j'aime pas en C++ et que je trouve plus clean en java c'est le fait qu'il y ait pas de reference. Les references du C++ ca fait trop de chose en meme temps. Bref, c'est propice aux effets de bords et aux bugs. Attention : Ceux qui sont des brute en C++ ne feront pas l'erreur, mais je ne parle pas de killer en C++, je parle du langage en lui meme.
* Päs d'inner class, ca c'est pas cool. Je trouve que c'est le concept le plus joli que j'ai vu en OO pour modeliser un call back.
* Pas de genericite, ca c'est pas cool. Ca veut dire tout plein de cast pas beaux (et donc une probabilite de se planter au runtime) dans la librairie standard. Pour moi un container se doit d'etre type. Le container qui contient n'importe quoi n'est qu'un container parmi tant d'autre.
[^] # Re: erratum
Posté par Epsos . En réponse à la dépêche Les gens votent-ils pour des idées sur linuxfr.org ?. Évalué à 10.
La quantite etant rarement synonyme de qualite, la democratie "betifie" la nation.
Bon, c'est un avis perso, je ne connais pas de meilleur systeme que la democratie, c'est donc le moins pire.
La proposition de Yeupou a sa place ici, car il s'agit d'un lieu de discussion. Bref, contrairement a la dictature, on peut donner son avis, et partir de la pour discuter, et eventuellement tomber d'accord.
Discuter c'est aussi parler a deux et argumenter. Aussi je trouve ton commentaire assez deplace : tu parles de dictature mais n'apporte rien a la discussion ...
Bel exemple ma foi.
[^] # Re: Erreurs de C++
Posté par Epsos . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 2.
Ex :
class A {int i}
class B : public A {}
class C : public A {}
class D : public B, C {}
D possede B::i et C::i ==> Super chiant.
On peut regler le probleme d'un seul coup en important tout le namespace de B (si on veut utiliser tout ce qui vient de B) ==>
class D : public B, C {using namespace B;} Ce qui permet d'eviter de nommer a chaque fois le chemin que l'on veut prendre.
En Java ce probleme ne se pose pas car une interface par definition ne contient que des methodes. Si deux methodes provenant de deux interfaces differentes ont le meme nom, tu n'as qu'une implementation (il y a des avantages et des inconvenients, c# a decide de permettre la resolution ==> On se retrouve avec deux methodes)
Bref, je suis pas d'accord avec ton terme d'heritage multiple, je parlerai plutot d'implementation multiple.
(Grosse difference entre C++ ou on "herite", et java ou on peut "etendre" et "implementer")
[^] # Re: Erreurs de C++
Posté par Epsos . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 6.
Des problemes se posent lors d'heritage en diamant par ex :
A
/ \
B C
\ /
D
D se retrouve avec 2 copies des methodes et des attributs de A. (un en passant par B, un autre en passant par C).
La plupart des problemes lies a l'heritage multiple c'est lors de la generation de code C++.
Pour faire de l'objet en C, grosso modo ce qu'on fait, c inclure la structure de la classe de base dans la classe derivee. De cette maniere, puisque les offsets des attributs sont toujours les memes, on se pose pas de question.
struct Base
{
byte i; // offset 0
byte j; // offset 1
}
struct derivate
{
struct Base base; // sizeof(Base) => 2
byte k; // offset 2
}
Lorsque tu as un heritage en diamant, comment tu calcules les offsets pour acceder a tes attributs ? On s'en sort en faisant du padding (en mettant des espaces entre les donnees) et en gerant l'acces aux attributs grace a un tableau qui indique comment acceder a un attribut donne suivant le type, mais ca complique les choses, et surtout ca ralentit pas mal l'execution du programme. On a le meme genre de probleme avec les methodes.
Tout ca pour dire que l'heritage multiple ca peut servir, mais souvent on s'en sort beaucoup mieux en revoyant son arbre d'heritage pour enlever les heritages multiples : l'arbre en general devient plus clair (mais c'est bien sur), preuve en general d'une meilleure architecture.
Le polymorphisme, (plusieurs formes, y a des latinistes dans le coin ??) permet a un objet d'un type donne de se faire passer pour un autre objet, ce qui est hyper pratique.
Ex : Tu as un arbre d'heritage
Vehicule
| \
Voiture Camion
Ton code :
Vehicule myVehicule = new Voiture();
==> Tu fait passer ta Voiture pour un Vehicule (normal une voiture est un vehicule)
==> Du code ecrit pour un vehicule fonctionnera a la fois pour une voiture et pour un camion.
Mais lorsque tu "overloade" une methode, ca te permet de changer la methode que tu vas appeler de facon transparente.
Ex :
myVehicule.f()
Si myVehicule est une Voiture, ca va appeler la methode f de Voiture, si myVehicule est un Camion, ca va appeler la methode f de Camion, etc...
Bon, tout ca est assez succinct, si tu veux un bon bouquin (online) pour commencer a voir ce que c'est que l'OO, va voir http://www.ibiblio.org/pub/docs/books/eckel/(...) et recupere "Thinking in java".
Tous les langages orientes objet (OO) implementent le polymorphisme, et l'heritage simple. Certains implementent aussi l'heritage multiple (C++, autre ?) plus d'autres "features" (RTTI, genericite, Reflexion, polymorphisme de methode, exceptions, ...).
[^] # Re: Erreurs de C++
Posté par Epsos . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 3.
Voila les genres d'optimisations que te laisse faire le C++ : inline, const, virtual, ref, ... Ce sont avant tout des optimisations de bas niveau. Des optimisations qui te font perdre du temps alors que le compilateur pourrait et devrait (comme KCC) les faire a ta place.
En Java, on ne te laisse pas le loisir de faire des optimisations de bas niveaux parce que la JVM devrait le faire a ta place (mais c'est vrai avec n'importe quel compilo optimisant)
En fait, le C++ est cense etre un langage objet. Qui dit objet dit haut niveau, qui dit haut niveau dit : on l'utilise pour se prendre la tete sur des problemes haut niveaux. Si j'ai envie de me prendre la tete sur des problemes plus bas niveaux, je vais prendre des langages plus bas niveaux : le C ou a l'extreme l'assembleur : j'utilise le langage adapte a mes objectifs et a mon probleme. Avec le C++ on te donne l'illusion de faire du haut niveau alors que tu dois quand meme te prendre la tete avec des problemes bas niveaux. En Java non. Oui je suis d'accord rien ne t'empeche de faire de l'assembleur en C++. Dans ces cas la personnellement je prefere prendre un assembleur que du C++.
Simple question de decoupage de probleme.
[^] # Re: Erreurs de C++
Posté par Epsos . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 3.
J'ajouterai juste que tu parles de quelqu'un qui s'y connait. Qui connait deja la plupart des pieges et qui sait s'en depatouiller. Bref, pas a la portee du premier venu. C'est pourquoi personnellement je prefere Java : le langage a justement ete cree (designe) de telle maniere qu'on ne puisse pas faire la plupart des erreurs qu'un debutant en C++ ferait.
De plus, Java incite a se concentrer sur l'algorithmique et non pas sur l'optimisation. Chose qu'on ne fait pas en c++, car comme tu dis en C++ on est conscient qu'un appel virtuel ca coute du temps, ... Mais il y a pire : si tu met ou il faut comme il faut des const tu permet au compilo de faire plus d'optimisations. Tu peux aussi declarer tout un tas de methodes inline pour encore plus optimiser ton code.
Ou je veux en venir ?? A ceci :
en C++ on perd trop de temps a penser son programme en tant qu'architecture + optimisation. Resultat au lieu de penser architecture propre, on degrade le cote architecture pour le cote optimisation, et a la fin on a un truc qui pourrait etre largement mieux d'un point de vue architecture.
Le point de vue de Java c'est : pensez architecture ! Les optimisations, c la JVM qui s'en charge. Ca ne doit pas etre votre probleme.
Bon, ca c'est la theorie. En pratique la JVM fait tourner ton programme nettement moins vite que ton compilo C++. Mais je trouve que ca va dans le bon sens. Et c'est ca qui compte. Car finalement le compilateur (ou la JVM) est l'entite la mieux place pour savoir ou mettre les optimisations.
Maintenant combien de temps ca prendra pour optimiser mieux que le programmeur ??
On arrive deja a pondre du code assembleur meilleur que le pekin qui s'y connait, je pense que cette etape viendra. Peut etre pas tout de suite mais elle viendra. Et en attendant, mieux vaut penser architecture propre, puis refaire une passe optimisation que l'inverse ... :-)
[^] # Re: Erreurs de C++
Posté par Epsos . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 5.
Ce qui est possible en C++, ce sont les nested class, pas les inner class.
Difference entre une nested et une inner :
l'inner class garde une sorte de pointeur vers la classe enclosing, ce qui fait qu'on peut se servir de l'inner classe comme d'un callback vers la classe enclosing. Classe qui aura acces a toutes les methodes et a tous les attributs de la classe enclosing.
# Erreurs de C++
Posté par Epsos . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 10.
* Le mot clef virtual : la plupart des gurus objet expliquent que le but de l'objet est de faire de l'objet !! C'est a dire utiliser du polymorphisme : toutes les methodes devraient etre polymorphique par defaut : ca evite des bugs. Quand on donne a une methode le nom d'une methode de la classe mere, c'est qu'on veut l'overloader !
* Les references : Il y a un truc que j'aime pas en C++ et que je trouve plus clean en java c'est le fait qu'il y ait pas de reference. Les references du C++ ca fait trop de chose en meme temps. Bref, c'est propice aux effets de bords et aux bugs. Attention : Ceux qui sont des brute en C++ ne feront pas l'erreur, mais je ne parle pas de killer en C++, je parle du langage en lui meme.
* Päs d'inner class, ca c'est pas cool. Je trouve que c'est le concept le plus joli que j'ai vu en OO pour modeliser un call back.
* Pas de genericite, ca c'est pas cool. Ca veut dire tout plein de cast pas beaux (et donc une probabilite de se planter au runtime) dans la librairie standard. Pour moi un container se doit d'etre type. Le container qui contient n'importe quoi n'est qu'un container parmi tant d'autre.