Java, un bon choix pour mes besoins ?

Bonjour,

Je suis un fervent défenseur du C++ et depuis quelques temps déjà je travaillais sur un projet de jeu en C++.
Je voulais entre-autre :

• répartir tout le jeu dans un système de pluggin pour permettre à tous de "moder" ce jeu sans recompiler tout le projet ainsi que de pouvoir changer les dépendances (bibliothèques) si l'une d'entre elle n'était pas supportée sur une plateforme ou devenait obsolète ;
• permettre l'exécution du programme via navigateur (en jouant un peu avec les Websocket et un serveur en Node.js, le principe est assez simple).

Sauf que je rencontre pas mal de problèmes :

• le système de pluggin est relativement long à développer ;
• l'exécution via navigateur prendra aussi un certain temps et demandera soit que tous les calculs soient effectués côté serveur, soit de réécrire un client en JavaScript ;
• la non-portabilité des exécutables me dérange aussi quelque peu, je peux difficilement demander aux utilisateurs de compiler eux-même (s'il faut recompiler des dépendances, ou autre ça peut très vite devenir "enquiquinant").

Même si je ne porte pas vraiment le Java dans mon cœur, je suis très sérieusement en train de songer à cette possibilité, ceci :

• me fera gagner un peu de temps pour la partie "exécution via navigateur" grâce aux applets ;
• facilitera le système de pluggin (un pluggin sera alors un .class qu'on chargera dynamiquement ?) ;
• m'évitera quelques cheveux blancs quant à la portabilité de mon jeu ;
• permettra une exécution sur téléphones (?)

Mais je me pose quelques questions :

• niveau performances, est-ce qu'il pourra tenir correctement de la 3D ? En effet, il est très difficile de faire des scènes 3D "légères" et sur des prototypes en C++ que j'ai réalisé (affichage de 9*6 objets identiques), je pouvais avoir un nombre de FPS relativement faible. Java ayant des bibliothèques encapsulant openGL, je suppose que les performances sont relativement égales ? Mais j'entends dire que le Java serait 30% à 70% moins performants que des langages natifs par rapport à la 3D :? ;
• est-ce que l'exécution sur téléphone est réaliste par rapport aux performances des téléphones actuels ? Est-ce que vous pensez qu'il pourrait y avoir des adaptations à faire ? Si oui, lesquelles ?
• En revanche, j'ai entendu dire que le Garbage collector posait quelques problèmes de performances pour ce type d'application, est-ce qu'il y a moyen de pallier cela ?
• est-ce que le Java vous semble un bon choix pour ce cas là ?

Est-ce que vous auriez d'autres conseils à me donner ?

Salut,

Je ne peux pas te répondre sur tous les points (en particulier sur la partie mobile où je n'y connais rien), mais à mon avis, oublie l'argument "applet" pour l'exécution côté navigateur, la technologie semblant virer à l'obsolescence, probablement à cause de nombreux problèmes de sécurité. Pour la partie plugin, regardes du côté OSGI : c'est, à mon avis, un excellent support pour la gestion de la modularité (notamment multi-plateforme).

Globalement, je verrasi bien une solution hybride java/osgi, C/C++ (via JNI, comme par exemple JOGL pour la 3D) + javascript pour l'exécution côté navigateur (via des bibliothèques style angular, par exemple, pour gagner du temps sur les dev).

Hello,

Niveau performance, si tu es limité par le GPU tu ne devrais voir quasiment aucune différence. Chaque appel à une fonction native (OpenGL par exemple) aura un léger surcout qui devrait être négligeable par rapport au temps que prendra la fonction.
L'exception étant : si tu as de très nombreux (et court) appels à DrawPrimitives / DrawIndexedPrimitives, là tu sentira vraiment le surcout. Mais si c'est le cas, tu auras de toutes façons des performances faibles aussi en C++ : surement un problème de conception / optimisation.

Si tu es limité par le CPU, alors le passage à Java se fera sentir.

Pour la portabilité du code, tu peux fournir un exe Windows, et les sources. Un utilisateur de Linux à déjà probablement dû compiler lui-même de nombreux programmes et devrait savoir le faire.
Mais sur ce point... C'est vrai que le C++ c'est pas la joie.

Merci pour vos réponses,

Citation:

---

Envoyé par joel.drigo

Pour la partie plugin, regardes du côté OSGI : c'est, à mon avis, un excellent support pour la gestion de la modularité (notamment multi-plateforme).

---

Ceci me semble très intéressant et m'évitera de devoir le coder moi-même.
Par contre je ne trouve pas vraiment de détails "buvables" quant à son fonctionnement :?

Citation:

---

Envoyé par joel.drigo

javascript pour l'exécution côté navigateur (via des bibliothèques style angular, par exemple, pour gagner du temps sur les dev).

---

Le problème c'est qu'il faudra réécrire une partie du code en JavaScript :?
Peut-être vaudrait-il mieux créer un client "léger" qui téléchargera les ressources qu'à partir du moment où il en aura besoin ?

Citation:

---

Envoyé par Neckara

Le problème c'est qu'il faudra réécrire une partie du code en JavaScript :?

---

Regarde du coté de emscripten, il est possible que tu n'ai pas grand chose à changer / refaire. ;)
(Niveau performance ça à l'air correct, en particulier avec asm.js.)

Citation:

---

Envoyé par Iradrille

Regarde du coté de emscripten, il est possible que tu n'ai pas grand chose à changer / refaire. ;)
(Niveau performance ça à l'air correct, en particulier avec asm.js.)

---

Je connais emscripten, mais :

• j'ai peur que cela ne pose des problèmes si j'utilise trop de bibliothèques
  
  • il faudra compiler les bibliothèque pour emscripten ;
  • avoir trop d'indirection risque de se voir au niveau des performances ;
  • certaines bibliothèques pourrait ne pas être compatibles avec emscripten (?)
  
  
• pour l'utilisation de la 3D, je ne sais pas si tous les navigateurs vont supporter la charge requise par emscripten.

Pour avoir un peu trempé dans ce genre de problématique, franchement, l’exécution sur navigateur, il n'y a pas de solution idéale. Comme déjà dit, les applets sont en train de devenir obsolètes. Si tu veux faire de la 3D, tu seras obligé de les signer. Et si tu ne le fait pas par un vrai certificat (payant), les utilisateurs devront mettre la sécurité java au minimum et elles risquent de ne plus fonctionner à tout moment (le message d'avertissement actuel prévient que les applets non signées par certificat reconnu seront bloquées ultérieurement).

Concernant le passage Java desktop <-> Android, c'est loin d’être aussi facile qu'on pourrait le croire. Le plus simple, selon moi, serait d'utiliser un moteur 3D qui est déjà compatible. Par exemple JMonkey qui est open source et gratuit. Il y a pas mal de videos qui trainent sur ce moteur qui montrent des exemples. Ca donne une idée des performances. Ceci dit, dans le monde du C++, des moteurs capables de générer du code ou des exécutables pour android existe peut être aussi...

Au sujet des performances, franchement, je ne suis pas sur qu'il y ait une si grosse différence. Quand on voit ce que font certains jeux, on se dit que ceux qui mettent à genoux une carte graphique en affichant 15 modeles 3D ne s'y prennent pas comme il faut. Meme s'il faut reconnaitre que c'est plus simple de dire que l'outil est mauvais plutot que de reconnaitre que l'architecture choisie ne convient pas :)

As-tu regardé du coté de Unity pour les jeux 3D qui s'exécutent dans le navigateur du client ?
Le développement se fait au choix en C# ou JavaScript il me semble. Après je ne sais pas si ce code est ensuite exécuté dans une VM ou bien compilé en binaire.
Mais bon, que ce soit en Java ou C# les problèmes liés au Garbage Collector seront les mêmes.
Pour faire des mods je ne suis pas sur. Et puis Minecraft ne se lance pas à partir du navigateur il me semble ?

PS: Si je puis me permettre : "Même si je ne porte pas vraiment le Java dans mon cœur", pourquoi ?
Je suis moi-même développeur C++, et pourtant je ne peux pas nier les qualités de Java.

Citation:

---

Envoyé par Gugelhupf

PS: Si je puis me permettre : "Même si je ne porte pas vraiment le Java dans mon cœur", pourquoi ?
Je suis moi-même développeur C++, et pourtant je ne peux pas nier les qualités de Java.

---

Java a certes des qualités mais je n'aimes pas certaines décisions qui ont été prises par les créateurs du Java :

• tout hérite de Object ;
• héritage multiple interdit, sauf qu'on peut "implémenter" plusieurs interfaces ce qui ressemble assez à une forme d'héritage :aie:
• pas de destructeurs à proprement parler (finalize qui est "peut-être" appelé) ;
• on ne peut pas vraiment séparer les prototypes de l'implémentation, je trouve, personnellement, que ça pose des problèmes de relecture du code (ou alors, il faut créer une interface) ;
• il me semble que tout a une sémantique d'entité et on ne peut pas créer de classe à sémantique de valeur si je ne m'abuse ;
• on gère la mémoire à notre place, plutôt que de nous donner un "choix".
• pour les prototypes de méthodes, certaines choses me paraissent lourdes car il faut les vérifier soit-même à la main
  
  • pas d'entiers non-signés
  • pas d'indications pour spécifier non-nuls
  
  
• il ne me semble pas qu'une méthode puisse retourner un objet constant (?), il faut donc faire une copie de l'objet avant de retourner sa copie si je ne m'abuse.
• l'ancienne gestion des I/O par "couche" me paraissait lourde et peu pratique.

Et par rapport au C++, je regrette :

• la surcharge d'opérateurs
• les templates (même si je ne les utilise pas souvent).

Mais bon, je ne vais tout de même pas me mettre à troller en territoire ennemis. http://chat.developpez.com/smileys/7787-acdf.gif

Citation:

---

Envoyé par Neckara

tout hérite de Object ;

---

C'est normal, car grâce à ce super type, les classes peuvent bénéficier de la méthode equals() par exemple.
Java ne possédant pas de surcharge d'opérateur cela devient utile.
La surcharge d'opérateur peut te manquer, mais le fait d'en avoir peut pousser les développeurs à les utiliser pour des opérations qui ne sont pas cohérentes, comme : "Mouton > Oiseau".
Seule la classe String possède des bonus par défaut (pour concaténer avec "+" par exemple), il aurait peut-être été agréable d'en avoir pour BigDecimal et BigInteger, mais ce n'est pas le cas.

Citation:

---

Envoyé par Neckara

héritage multiple interdit, sauf qu'on peut "implémenter" plusieurs interfaces ce qui ressemble assez à une forme d'héritage :aie:

---

Ça reste une forme d'héritage avec une classe ne possédant que des méthodes virtuelles pures, l'idée étant d'éviter le Deadly Diamond Of Death, problème qu'on peut rencontrer dans les langages comme C++ ou Python.
L'héritage multiple n'a jamais été un gros problème lorsque la conception est bonne (avec les bons design pattern).
De plus en Java 8, il est possible d'avoir des méthodes par défaut, ou des méthodes static dans les interfaces, afin de combler les lacunes des frameworks qui essayent de garder la rétrocompatibilité.

Citation:

---

Envoyé par Neckara

pas de destructeurs à proprement parler (finalize qui est "peut-être" appelé) ;

---

Il n'y a pas besoin de destructeur pour libérer les ressources en Java. Les instances sont libérés automatiquement grâce à la VM.
Il reste toujours des ressources à libérer, si tu ouvres un fichier par exemple, il faut le fermer avec close().
De plus depuis Java 7, il est possible d'utiliser une sucre syntaxique (try-with-ressources lien doc), qui te permet d'entrer moins d'instructions, et le fichier sera fermé proprement (implicitement mais de façon déterminé).

Citation:

---

Envoyé par Neckara

on ne peut pas vraiment séparer les prototypes de l'implémentation, je trouve, personnellement, que ça pose des problèmes de relecture du code (ou alors, il faut créer une interface) ;

---

Il y a longtemps, mon enseignant C++ nous avait dit qu'un avantage de séparer les prototypes de l'implémentation était de cacher l'implémentation au client. Donc rendre celui-ci dépendant de votre produit en somme.
Personnellement je travaille avec des IDE, et j'ai horreur de séparer la structure de ma classe de son implémentation. Sinon ça fait 2 fichiers à ouvrir. Donc si j'ai 8 classes ouvertes, je devrais en avoir 8 de plus pour l'implémentation (ce qui fait beaucoup d'onglets).
Donc même en C++ je place l'implémentation au sein de la classe.
Le fait est que grâce à l'IDE, je peux rapidement atteindre une méthode que je veux au sein de la même page.

Citation:

---

Envoyé par Neckara

il me semble que tout a une sémantique d'entité et on ne peut pas créer de classe à sémantique de valeur si je ne m'abuse ;

---

En effet, à part les 8 variables primitives (int, double etc...), tout est classe...
Mais plus pour longtemps, en Java 9 il est fort probable que nous ayons les Value Types.
Article récent qui traite du sujet ici.

Citation:

---

Envoyé par Neckara

on gère la mémoire à notre place, plutôt que de nous donner un "choix".

---

Oui, d'où l'intérêt de Java, aller à l'essentiel des choses.
Aujourd'hui en C++ on te donne le choix entre des pointeurs qui risquent de te causer des problèmes de fuite de mémoire lorsque tu as une exception, et des pointeurs intelligents dont la syntaxe est imbuvable.

Citation:

---

Envoyé par Neckara

pour les prototypes de méthodes, certaines choses me paraissent lourdes car il faut les vérifier soit-même à la main

---

Je n'ai pas compris :aie:

Citation:

---

Envoyé par Neckara

pas d'indications pour spécifier non-nuls

---

En Java 8, tu as des annotations pour spécifier les non-nuls. Lien ici. Mais je t'avouerais que je ne me suis pas suffisamment formé là-dessus.
Aussi, peut-être que je confonds avec autre chose. Comment fait-t-on pour spécifier les non-nuls en C++ ?

Citation:

---

Envoyé par Neckara

l'ancienne gestion des I/O par "couche" me paraissait lourde et peu pratique.

---

Oui, c'est pour cela que depuis Java 7, tu as la classe Paths.
Au faite, peux-tu me rappeler comment on fait, de façon standard en C++, pour gérer les répertoires ? ;)

Citation:

---

Envoyé par Neckara

les templates (même si je ne les utilise pas souvent).

---

Les génériques, cousin du template :p

Citation:

---

Envoyé par Neckara

il ne me semble pas qu'une méthode puisse retourner un objet constant (?), il faut donc faire une copie de l'objet avant de retourner sa copie si je ne m'abuse.

---

En Java tu as des constantes (final), mais en effet, tu ne peux pas forcer une méthode à te retourner un attribut qui est final. Ensuite le développeur suffisamment malin saura faire la distinction entre retourner la référence, ou une copie de son objet, voir même créer un type immuable.


Pour les entiers non signés, oui, ça peut être utile pour allonger la plage de valeur. Mais ce n'est pas quelque chose de catastrophique non plus (ils ne l'ont peut-être pas ajouté à cause du fait que le langage soit multiplateforme, ou bien par simplicité). Une fois on m'a fait la reproche comme quoi on pouvait mettre des valeurs négatives au niveau de l'indice d'un tableau en Java, à cause du fait qu'il manque les types non signés... ah bon, parce qu'on ne vérifie plus la valeur min et max du tableau ? :aie:
Et puis celui qui ne tombe pas dans le piège du < 0 avec un type non signé, tombera peut-être dans celui du array index out of bound.

Bon, je pense que j'ai eu mes réponses sur ce sujet, je vais le passer en résolu.

On va partir un peu en HS, mais je pense que cela pourra m'être très instructif^^.

Citation:

---

Envoyé par Gugelhupf

La surcharge d'opérateur peut te manquer, mais le fait d'en avoir peut pousser les développeurs à les utiliser pour des opérations qui ne sont pas cohérentes, comme : "Mouton > Oiseau".

---

Donc à cause de "mauvais programmeurs", on sanctionne tous les "bons programmeurs" ?
Si on suit cette logique, on pourrait nous empêcher d'écrire des logiciels car cela pourrait pousser les développeurs à les utiliser pour écrire des logiciels qui ne serait pas "cohérent"/bogué.

De plus, ceci n'empêche pas de faire : max(mouton, oiseau); ou mouton.isGreaterThan(oiseau);Personnellement, je préfère avoir des règles tacites :

• comparaisons "absolues" entre entité interdite car cela n'a aucun sens ;
• les opérateurs doivent conserver leurs signification

Citation:

---

Ça reste une forme d'héritage avec une classe ne possédant que des méthodes virtuelles pures, l'idée étant d'éviter le Deadly Diamond Of Death, problème qu'on peut rencontrer dans les langages comme C++ ou Python.

---

Le problème, c'est qu'en tentant d'éviter un cas particulier, on restreint les possibilités alors qu'il pourrait exister des solutions, je pense, moins radicales.

Citation:

---

L'héritage multiple n'a jamais été un gros problème lorsque la conception est bonne (avec les bons design pattern).

---

Dans certains rares cas, il permet d'éviter un peu de duplication de code tout en restant cohérent, mais je reconnais que c'est assez rare d'utiliser de l'héritage multiple.

Citation:

---

De plus en Java 8, il est possible d'avoir des méthodes par défaut, ou des méthodes static dans les interfaces, afin de combler les lacunes des frameworks qui essayent de garder la rétrocompatibilité.

---

Des "méthodes par défaut" ?? Mais ce n'est plus des interfaces alors :koi:

Citation:

---

Il n'y a pas besoin de destructeur pour libérer les ressources en Java. Les instances sont libérés automatiquement grâce à la VM.
Il reste toujours des ressources à libérer, si tu ouvres un fichier par exemple, il faut le fermer avec close().

---

Seule la mémoire est libérée par défaut, mais pas les autres ressources, donc si on oublie un close(), cela peut devenir assez coûteux.
Le fait de libérer toutes les ressources à la destruction de l'objet, permet justement d'éviter ce genre de problème.

Citation:

---

De plus depuis Java 7, il est possible d'utiliser une sucre syntaxique (try-with-ressources lien doc), qui te permet d'entrer moins d'instructions, et le fichier sera fermé proprement (implicitement mais de façon déterminé).

---

J'en ai entendu parler, mais gère-t-il bien tout types de ressources ?
De plus j'ai un peu l'impression que c'est une sorte de "rustine" pour tenter de combler ce petit défaut du Java.

Citation:

---

Personnellement je travaille avec des IDE, et j'ai horreur de séparer la structure de ma classe de son implémentation. Sinon ça fait 2 fichiers à ouvrir. Donc si j'ai 8 classes ouvertes, je devrais en avoir 8 de plus pour l'implémentation (ce qui fait beaucoup d'onglets).

---

Là c'est plus un problème dû à l'IDE.
Pour passer de l'en-tête au fichier source, avec un bon IDE, c'est fait en même pas 0,5 secondes (un clic sur un prototype ou un raccourcit touche).
Pour les onglets... personnellement j'ai tout le temps la liste des fichiers du projet à ma droite et c'est elle que j'utilise pour naviguer.

Citation:

---

Donc même en C++ je place l'implémentation au sein de la classe.

---

Ce que je trouve dommage, c'est quand on se retrouve avec une classe de 300 lignes ou plus, on ne peut pas voir d'un simple coup d’œil toutes les membres de la classe, il faut générer la doc pour avoir une vision d'ensemble claire.

Citation:

---

En effet, à part les 8 variables primitives (int, double etc...), tout est classe...
Mais plus pour longtemps, en Java 9 il est fort probable que nous ayons les Value Types.
Article récent qui traite du sujet ici.

---

Très intéressant :ccool:

Citation:

---

Oui, d'où l'intérêt de Java, aller à l'essentiel des choses.

---

Sauf que parfois, on veut pouvoir gérer soit-même sa mémoire et Java n'offre pas cette possibilité ce qui est assez dommage.
Il aurait été intéressant d'avoir par exemple :

• par défaut
  
  • allocation automatique, libération à la fin du bloc/destruction de la classe
  • allocation avec le garbage collecteur (new)
  
  
• si on le spécifie explicitement
  
  • gestion via ce que le dev veut.
  
  

Citation:

---

Aujourd'hui en C++ on te donne le choix entre des pointeurs qui risquent de te causer des problèmes de fuite de mémoire lorsque tu as une exception,

---

Avec les containers et le principe RAII, cela pose un peu moins de problèmes.

Citation:

---

et des pointeurs intelligents dont la syntaxe est imbuvable.

---

Personnellement, je les trouve loin d'être imbuvable.

Citation:

---

Je n'ai pas compris :aie:

---

Il faut que tu vérifie toi-même si la valeur n'est pas nulle ou négative, ensuite il faut lancer une exception, mettre dans le prototype de ta fonction que tu lance une exception, mettre un try/catch, etc.

Citation:

---

En Java 8, tu as des annotations pour spécifier les non-nuls. Lien ici. Mais je t'avouerais que je ne me suis pas suffisamment formé là-dessus.
Aussi, peut-être que je confonds avec autre chose.

---

Je ne connaissais pas, il faudrait que je teste un de ces jours.
En même temps Java 8 est un peu récent non?

Citation:

---

Comment fait-t-on pour spécifier les non-nuls en C++ ?

---

Passage par copie ou par référence.

Citation:

---

Oui, c'est pour cela que depuis Java 7, tu as la classe Paths.

---

? Non je parlais des :

Code:

---

new BiduleStreamInput(new BiduleReaderInput(new BiduleBufferInput(new BiduleInput) ) )

---

D'ailleurs, il ne me semble pas qu'on pouvait ouvrir des fichiers en lecteur et écriture ?

Citation:

---

Au faite, peux-tu me rappeler comment on fait, de façon standard en C++, pour gérer les répertoires ? ;)

---

On utilise boost :langue: (c'est un coup bas ce que tu nous fais là).

Citation:

---

Les génériques, cousin du template :p

---

Oui, j'ai un peu oublié :oops:.

Il y a des spécialisation de génériques ? :p (moi aussi j'sais faire des coups bas :langue2:)
Il ne me semble pas (à vérifier) qu'on puisse passer d'autres choses que des noms de classes aux génériques ?

Citation:

---

En Java tu as des constantes (final), mais en effet, tu ne peux pas forcer une méthode à te retourner un attribut qui est final. Ensuite le développeur suffisamment malin saura faire la distinction entre retourner la référence, ou une copie de son objet, voir même créer un type immuable.

---

Oui mais les copies peuvent être coûteuses ou incohérente et créer une classe immuable est trop long, pour nous, pauvres développeurs fainéants.

Citation:

---

Pour les entiers non signés, oui, ça peut être utile pour allonger la plage de valeur. Mais ce n'est pas quelque chose de catastrophique non plus (ils ne l'ont peut-être pas ajouté à cause du fait que le langage soit multiplateforme, ou bien par simplicité). Une fois on m'a fait la reproche comme quoi on pouvait mettre des valeurs négatives au niveau de l'indice d'un tableau en Java, à cause du fait qu'il manque les types non signés... ah bon, parce qu'on ne vérifie plus la valeur min et max du tableau ? :aie:
Et puis celui qui ne tombe pas dans le piège du < 0 avec un type non signé, tombera peut-être dans celui du array index out of bound.

---

Ben on a plus qu'une vérification à faire au lieu de deux, c'est autant de risques en moins d'avoir une erreur.

Sinon si je veux avoir une distance, cette dernière ne pouvant être négative, je vais me payer une vérification gratuite :aie:.
Cela peut même permettre, lorsqu'on attend un entier positif ou égal à -1 dans un cas d'erreur, de considérer que la valeur maximale pouvant être prise par le type sera le cas d'erreur et ainsi de n'avoir qu'une vérification à faire.



En tout cas, je trouve que ce type d'échange est très instructif malheureusement, cela se transforme trop souvent en guerre de religion ou en troll.
Je suis assez content de pouvoir avoir un échange constructif et serein avec vous alors que je critique un peu un langage que vous semblez aimer :ccool:.
(bon, je reconnais troller parfois sur le chat, mais bon, c'est le chat quoi :aie:)

Citation:

---

Envoyé par Gugelhupf

Il n'y a pas besoin de destructeur pour libérer les ressources en Java. Les instances sont libérés automatiquement grâce à la VM.
Il reste toujours des ressources à libérer, si tu ouvres un fichier par exemple, il faut le fermer avec close().

---

C'est justement à ça que sert un destructeur, on à la garantie que la ressource sera relachée dès que l'objet est détruit.
A priori un équivalent à "try-with-ressources", mais directement intégré à la classe.

Citation:

---

Envoyé par Gugelhupf

En Java 8, tu as des annotations pour spécifier les non-nuls. Lien ici. Mais je t'avouerais que je ne me suis pas suffisamment formé là-dessus.
Aussi, peut-être que je confonds avec autre chose. Comment fait-t-on pour spécifier les non-nuls en C++ ?

---

En C++ un pointeur peut être nul (et réassigné), c'est très proche d'une référence en Java. En C++ une référence ne peut pas être nulle (ni réassignée)

Code:

---

1 2 3 4 5 6

int i, j = 42; int *p = nullptr; // pointeur null p = &i; // qui pointe maintenant sur i   int& r = i; // r est une ref sur i, r est forcément non nulle r = j; // equivalent à i = j, une ref ne peut pas être réassignée

---

Citation:

---

Envoyé par Gugelhupf

Au faite, peux-tu me rappeler comment on fait, de façon standard en C++, pour gérer les répertoires ? ;)

---

Boost.filesystem, normalement bientôt ajouté à la norme. ;)

Citation:

---

Envoyé par Gugelhupf

Les génériques, cousin du template :p

---

Venant du C++, les generics (Java ou C#) c'est vraiment le gros point noir de ces langages, le fait de devoir définir des interfaces limite vraiment l'utilisation.
(En tout cas, c'est ce qui me dérange le plus).

Citation:

---

Envoyé par Neckara

max(mouton, oiseau); ou mouton.isGreaterThan(oiseau);

---

Je joue sur les mots mais dire que Mouton "est supérieure à" (greaterThan) Oiseau n'a aucun sens.
Dire que Mouton est "plus grand" (biggerThan) ou "plus gros" (fatterThan) que Oiseau oui.
Le fait est que à part les types particuliers comme String, des entiers/décimaux, des types monétaires, et dates/heures, utiliser des opérateurs n'est pas utile, ou peut pousser à un mauvais usage des conventions d'écriture du langage Java.

Citation:

---

Envoyé par Neckara

Des "méthodes par défaut" ?? Mais ce n'est plus des interfaces alors :koi:

---

Si tu considères qu'une interface ne peut être constitué que de méthode virtuelle pure, les interfaces Java ne sont plus de vraies interface :aie:

Citation:

---

Envoyé par Neckara

Seule la mémoire est libérée par défaut, mais pas les autres ressources, donc si on oublie un close(), cela peut devenir assez coûteux.
Le fait de libérer toutes les ressources à la destruction de l'objet, permet justement d'éviter ce genre de problème.

---

Citation:

---

Envoyé par Iradrille

C'est justement à ça que sert un destructeur, on à la garantie que la ressource sera relachée dès que l'objet est détruit.

---

Normalement, on est censé savoir quand et où on souhaite fermer un fichier, pas forcément à la fin d'un bloc pour faire intervenir le RAII (même en C++ tu as une méthode close() pour fermer ton oftream). Aussi ce type de ressource est généralement utilisé au sein d'un même bloc, donc sa manipulation n'est pas aussi complexe que les objets qu'on est susceptible de trimballer d'objet à objet.

Citation:

---

Envoyé par Neckara

J'en ai entendu parler, mais gère-t-il bien tout types de ressources ?
De plus j'ai un peu l'impression que c'est une sorte de "rustine" pour tenter de combler ce petit défaut du Java.

---

Tous les types de ressource qui implémente l'interface AutoCloseable, il ne reste plus qu'à croiser les doigts pour que la méthode close() soit implémenté correctement :aie:
Rustine non, c'est une syntaxe sucrée qui garanti (finally) qu'à la fin de ton bloc, tu vas fermer ta ressource.

Citation:

---

Envoyé par Neckara

Là c'est plus un problème dû à l'IDE.
Pour passer de l'en-tête au fichier source, avec un bon IDE, c'est fait en même pas 0,5 secondes (un clic sur un prototype ou un raccourcit touche).
Pour les onglets... personnellement j'ai tout le temps la liste des fichiers du projet à ma droite et c'est elle que j'utilise pour naviguer.

---

Ayant pratiqué les 2 types de développements (séparation prototype/implémentation, fichier unique par classe), j'en suis resté au second.

Citation:

---

Envoyé par Neckara

Ce que je trouve dommage, c'est quand on se retrouve avec une classe de 300 lignes ou plus, on ne peut pas voir d'un simple coup d’œil toutes les membres de la classe, il faut générer la doc pour avoir une vision d'ensemble claire.

---

Je ne sais pas quel IDE tu utilises, mais moi, en un coup d'oeil je peux voir les membres de la classe (inférieur à 0,5 secondes garanti :aie: ) :
Pièce jointe 146046

Citation:

---

Envoyé par Neckara

Avec les containers et le principe RAII, cela pose un peu moins de problèmes.

---

Je ne vois pas trop ce que peuvent faire les containers et le RAII contre les exceptions générés dans le constructeur de ta classe (voir ceci).

Citation:

---

Envoyé par Neckara

Il faut que tu vérifie toi-même si la valeur n'est pas nulle ou négative, ensuite il faut lancer une exception, mettre dans le prototype de ta fonction que tu lance une exception, mettre un try/catch, etc.

---

Oui, mais préciser dans le prototype de ta méthode que ta méthode est susceptible de lancer une exception (throws) est une excellente manière de documenter ton code (tous les langages de haut niveau ne le font pas si ça peut te rassurer). Et puis cela suit une logique, si la méthode d'une classe Parente lance une exception d'un certain type, celui de la méthode Enfant doit elle aussi lancer une exception de ce type, histoire de ne pas dénaturer le comportement de base de la méthode.
Ce n'est pas pour embêter le développeur avec les try/catch, l'approche est défensive.

Citation:

---

Envoyé par Neckara

En même temps Java 8 est un peu récent non?

---

Il a longtemps été attendu, mais oui, il vient de sortir récemment (18 mars 2014)

Citation:

---

Envoyé par Neckara

? Non je parlais des :

Code:

---

new BiduleStreamInput(new BiduleReaderInput(new BiduleBufferInput(new BiduleInput) ) )

---

D'ailleurs, il ne me semble pas qu'on pouvait ouvrir des fichiers en lecteur et écriture ?

---

C'est justement pour éviter tous ces InputStreamBidules imbuvables que tu as la classe Paths depuis Java 7.
Ouvrir en lecture et ouverture en même temps, non je ne crois pas, d'ailleurs, si cette possibilité n'est pas fournit, c'est qu'il doit forcément y avoir une raison.

Citation:

---

Envoyé par Neckara

Il y a des spécialisation de génériques ? :p (moi aussi j'sais faire des coups bas :langue2:)
Il ne me semble pas (à vérifier) qu'on puisse passer d'autres choses que des noms de classes aux génériques ?

---

Les génériques de base s'utilisent presque de la même manière que les templates de base.
Il n'y a pas de spécialisation ou de variadic template en Java... tout comme il n'y a pas de covariance et contravariance en C++ :mrgreen:
Mais sincèrement, en C++, j'ai rarement eu à utiliser la spécialisation, la syntaxe est juste lourde à mettre en place.
L'inconvénient en Java, contrairement au C# et C++, c'est que tu ne peux pas utiliser les types primitifs, il faut utiliser les Wrapper ("Integer" au lieu de "int" par exemple).
Un autre contrairement au C++, c'est l'instanciation du type template que tu ne peux pas.
Le compilateur C++, tout ce qu'il fait, c'est dupliquer du code (alourdir le binaire), ce qui n'est pas le cas en Java, qui lui cast (perte de performance). Pour C# c'est encore autre chose.

Citation:

---

Envoyé par Neckara

Oui mais les copies peuvent être coûteuses ou incohérente et créer une classe immuable est trop long, pour nous, pauvres développeurs fainéants.

---

Peut-être.. Je ne sais pas, mais un jour un gourou du C++ m'a répondu cela :
@lmghs

Citation:

---

il est parfois plus efficace de copier que de prendre des références. Il y a quelques articles à ce sujet sur cpp-next. Sans parler des rvalue-references qui changent encore la donne.
[...]
Parfois sur des objets plus gros cela donne aussi de meilleures performance. D'où que je t'envoie sur cpp-next. Les infos sont là bas.

---

Citation:

---

Envoyé par Neckara

Passage par copie ou par référence.

---

Citation:

---

Envoyé par Iradrille

En C++ un pointeur peut être nul (et réassigné), c'est très proche d'une référence en Java.

---

Je vais jouer sur les mots, mais il n'y a pas de référence en Java, c'est un abus de langage.
Suite à l'exemple, je comprends mieux de quoi il s'agit merci :)

Citation:

---

Envoyé par Gugelhupf

Oui, mais préciser dans le prototype de ta méthode que ta méthode est susceptible de lancer une exception (throws) est une excellente manière de documenter ton code (tous les langages de haut niveau ne le font pas si ça peut te rassurer).

---

Mais ça ne rend pas le code dur à maintenir ?
par exemple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

// ne pas faire attention à la syntaxe, j'ai pas d'IDE / compilo Java sous la main class Foo { public Foo() { } public void bar() throw SomeException { throw new SomeException(); } };   class Baz { private Foo foo; public Baz() { foo = new Foo(); } public void fct() throw SomeException { foo.bar(); } };

---

Si par la suite Foo::bar devient

Code:

---

1 2 3 4 5 6 7 8

public void bar() throw SomeException, SomeOtherException { if(...) { throw new SomeException(); } else { throw new SomeOtherException(); } }

---

Il faut modifier Baz::fct (et toutes les fonctions utilisant Foo::bar), ou alors il est inutile de préciser que Baz::fct peut "laisser passer" les exceptions de Foo::bar ?

Citation:

---

Envoyé par Gugelhupf

Je ne vois pas trop ce que peuvent faire les containers et le RAII contre les exceptions générés dans le constructeur de ta classe (voir ceci).

---

Code:

---

1 2 3 4 5 6 7 8 9 10

class A { std::unique_ptr<int> i; std::unique_ptr<int> j;   public: A(A const &) = delete; A& operator= (A const &) = delete;   A() : i(new int(314)), j(new int(42)) { } };

---

Le RAII (utilisé en interne par std::unique_ptr) résout le problème. ;)

Citation:

---

Envoyé par Gugelhupf

Je vais jouer sur les mots, mais il n'y a pas de référence en Java, c'est un abus de langage.
Suite à l'exemple, je comprends mieux de quoi il s'agit merci :)

---

Rhoo tu chipote, tu sais très bien de quoi on parle. :D

edit

Citation:

---

Envoyé par Gugelhupf

Normalement, on est censé savoir quand et où on souhaite fermer un fichier, pas forcément à la fin d'un bloc pour faire intervenir le RAII (même en C++ tu as une méthode close() pour fermer ton oftream).

---

Tout comme on est sensé savoir quand supprimer un objet pour relacher la mémoire. On peut fermer un fichier manuellement, mais si on le fait pas, on à quand même la garanti qu'il sera fermé dès que l'objet sera détruit.

Citation:

---

Envoyé par Gugelhupf

Je joue sur les mots mais dire que Mouton "est supérieure à" (greaterThan) Oiseau n'a aucun sens.
Dire que Mouton est "plus grand" (biggerThan) ou "plus gros" (fatterThan) que Oiseau oui.

---

Je n'ai pas dit le contraire.

Citation:

---

Le fait est que à part les types particuliers comme String, des entiers/décimaux, des types monétaires, et dates/heures, utiliser des opérateurs n'est pas utile, ou peut pousser à un mauvais usage des conventions d'écriture du langage Java.

---

Tu oublies les conteneurs, classes de lectures/écriture, tout ce qui est foncteurs et pointeurs.
Le opérateurs de conversions implicites peuvent être assez utile comme une conversion vers :

• std::string pour afficher une classe, en Java il faut appeler une méthode ToString() ;
• bool pour voir s'il n'y a pas eu d'erreur (ex, lecture de fichier)

On peut aussi interdire la copie d'entité, optimiser la copie de valeurs.
Les opérateurs sont donc loin d'être inutiles.
Je pense donc que l'utilité est bien supérieur au risque qui est même inexistant chez un bon nombre de développeurs.

Citation:

---

Normalement, on est censé savoir quand et où on souhaite fermer un fichier, pas forcément à la fin d'un bloc pour faire intervenir le RAII (même en C++ tu as une méthode close() pour fermer ton oftream).

---

Je n'ai pas dit le contraire, mais avoir une libération automatique éviter des bogues.
D'ailleurs, rien n'interdit de vouloir libérer la ressource à la fin du bloc ou à la destruction de la classe, ce qui est loin d'être rare.

Citation:

---

Aussi ce type de ressource est généralement utilisé au sein d'un même bloc, donc sa manipulation n'est pas aussi complexe que les objets qu'on est susceptible de trimballer d'objet à objet.

---

Donc tu ouvres et tu ferme ta base de donnée à chaque requête pour utiliser la ressource au sein d'un même bloc ? :aie: (ok, je troll)
Un bon nombre de ressources doivent rester ouverte au-delà du bloc où elles sont utilisée.

Citation:

---

Tous les types de ressource qui implémente l'interface AutoCloseable, il ne reste plus qu'à croiser les doigts pour que la méthode close() soit implémenté correctement :aie:
Rustine non, c'est une syntaxe sucrée qui garanti (finally) qu'à la fin de ton bloc, tu vas fermer ta ressource.

---

A la fin du bloc, pourquoi pas, mais est-ce que ceci marche aussi lors de la destruction de la classe ? Est-on sûr que finally sera appelé ?

Citation:

---

Je ne sais pas quel IDE tu utilises, mais moi, en un coup d'oeil je peux voir les membres de la classe (inférieur à 0,5 secondes garanti :aie: ) :

---

Je ne suis pas vraiment convaincu, la fenêtre doit prendre quand même pas mal de place si le prototype d'une méthode est un peu longue et a des throws.

Citation:

---

Je ne vois pas trop ce que peuvent faire les containers et le RAII contre les exceptions générés dans le constructeur de ta classe (voir ceci).

---

C'est simple, on évite de lancer des exceptions dans un constructeurs. :mouarf:
Si la construction peut échouer, soit on passe par une factory, soit on passe par une méthode MaClasse::create(), soit on donne une fonction pour vérifier la cohérence de la classe.

Citation:

---

Ce n'est pas pour embêter le développeur avec les try/catch, l'approche est défensive.

---

Déjà, il pourrait envoyer l'exception automatiquement, c'est toujours cela de gagné.
Ensuite, il suffit de fonction toute simples de conversion, pour ne plus à avoir à mettre des try/catch lors de l'appel des fonctions :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

@nonnull Toto t = coallapse(toto, new Toto(58) );   if( toto != null ) { @nonnull Toto t = coallapse(toto, null); // lance une exception si toto est null foo( toto) ; } else { // I do what I want. }

---

Ensuite, c'est avant tout à l'appeleur de vérifier qu'il envoie bien des données valides, donc en théorie de try/catch devrait être inutile.
Ce qui n'empêche pas la classe de vérifier elle-même la cohérence des données reçues, mais avec nonnull ou non-signé, elle n'a plus besoin de le faire.

Citation:

---

Ouvrir en lecture et ouverture en même temps, non je ne crois pas, d'ailleurs, si cette possibilité n'est pas fournit, c'est qu'il doit forcément y avoir une raison.

---

Ben personnellement, je n'en vois pas la raison :aie:.

Citation:

---

Il n'y a pas de spécialisation ou de variadic template en Java... tout comme il n'y a pas de covariance et contravariance en C++ :mrgreen:

---

En effet, par contre il faut faire attention de ne pas les utiliser pour des containers :aie:

Citation:

---

Peut-être.. Je ne sais pas, mais un jour un gourou du C++ m'a répondu cela :
@lmghs

---

En C++, :?
Cela ne me paraitrait pas logique dans le cas où on utiliserait des références.


Vous allez finir par me faire louper mon car :aie:

Citation:

---

Envoyé par Neckara

Bon, je pense que j'ai eu mes réponses sur ce sujet, je vais le passer en résolu.

---

Quand tu auras décidé, est ce que tu pourrais poster l'outil que tu vas utiliser (meme si ce n'est pas java) ? C'est une question que je me suis deja posée et je n'ai pas trouvé de réponse idéale donc ca m'interesse de voir ce que les autres choisissent dans le meme cas :)

Concernant Java/C/C++, j'ai un peu le chemin inverse. A la base, j'ai fait du C. puis du Java et en ce moment, je fais un peu de c++ (via des projets de jeux open source). Quand je suis arrivé sur Java, je trouvais embetant de ne pas avoir de macros et je trouvais le coté multiplateforme pas forcement tres utile. Mais la, pour rejouer un peu avec c++, je me rends compte à quel point c'est galere. Pour s'en rendre compte, il suffit de télécharger n'importe quel projet open source puis de compiler via MSVS, MinGW et Linux GCC. Deja, il y a de fortes chances que le projet ne compile pas sur les 3 (et je ne parle meme pas des autres compilateurs). Ensuite, quand on regarde les sources, il y a des flags sur les compilateurs dans tous les sens, c'est pas évident de savoir quel code est utilisé ou non.

Un autre truc qui me gene avec les macros, c'est les comportements différents en fonction de l'ordre des include (en général, une macro redefinit une fonction avec un nom un peu trop générique et ca pete le header suivant).
Quand à la séparation header/implementation, je pense comme Gugelhupf pour les memes raisons. C'est compliqué à lire et ca oblige à passer d'un fichier à l'autre. Et quand on veut modifier le prototype d'une fonction, il faut le faire 2 fois. C'est galère.

Citation:

---

Envoyé par hwoarang

Concernant Java/C/C++, j'ai un peu le chemin inverse. A la base, j'ai fait du C. puis du Java et en ce moment, je fais un peu de c++ (via des projets de jeux open source). Quand je suis arrivé sur Java, je trouvais embetant de ne pas avoir de macros et je trouvais le coté multiplateforme pas forcement tres utile. Mais la, pour rejouer un peu avec c++, je me rends compte à quel point c'est galere. Pour s'en rendre compte, il suffit de télécharger n'importe quel projet open source puis de compiler via MSVS, MinGW et Linux GCC. Deja, il y a de fortes chances que le projet ne compile pas sur les 3 (et je ne parle meme pas des autres compilateurs). Ensuite, quand on regarde les sources, il y a des flags sur les compilateurs dans tous les sens, c'est pas évident de savoir quel code est utilisé ou non.

---

C'est effectivement quelque chose de bien chiant en C++, si seulement ça pouvait être standardisé...

Pour les macros elles sont principalement utilisées pour définir des configurations : une fonction qui agit différemment en Debug et Release, l'import / export de fonctions dans les DLL etc.. (et protéger les includes).

En dehors de ça, l'utilisation de macros reste très rare et il faut avoir une bonne raison pour les utiliser : en C c'est la seule façon d'éviter des gros copier / coller, en C++ on à largement les outils pour s'en sortir sans macros : templates, constepr, surcharge de fonctions etc..
Si jamais on doit utiliser des macros, cette une bonne pratique de les undef dès qu'elles ne servent plus.

Code:

---

1 2 3 4 5 6 7 8

#define ITER_5(a) (foo((a)); foo((a)+1); foo((a)+2); foo((a)+3); foo((a)+4);) #define ITER_25(a) (ITER_5((a)); ITER_5((a)+5); ITER_5((a)+10); ITER_5((a)+15); ITER_5((a)+20);)   void foo(int i) { std::cout << i << " "; } ITER_25(0);   #undef ITER_5 #undef ITER_25

---

Pour dérouler une boucle à la main par exemple (c'est généralement inutile vu qu'un compilo sait le faire).
Puis une erreur de syntaxe dans une macro et ça devient vite un bordel monstre à corriger, les macros c'est vraiment en dernier recours. ;)

Citation:

---

Envoyé par hwoarang

Quand tu auras décidé, est ce que tu pourrais poster l'outil que tu vas utiliser (meme si ce n'est pas java) ? C'est une question que je me suis deja posée et je n'ai pas trouvé de réponse idéale donc ca m'interesse de voir ce que les autres choisissent dans le meme cas :)

---

Déjà, je vais adopter une approche plus POC au lieu de l'approche POO que j'adoptais tout en faisant du pseudo "POC" vu que je séparais mon code en "modules".

Ensuite, je vais essayer d'aller à l'essentiel et de faire simple.
Au départ, je voulais générer une interface C à partir de code ou de pseudo code C++ pour les modules pour des questions de portabilités, à partir de ce pseudo-code, je pensais pouvoir générer automatiquement un "squelette" pour mon module permettant ainsi d'écrire le module dans divers langages. Mais cela prend trop de temps à réaliser.
Je vais donc :

• fournir des interfaces C++, si une personne veut faire un module en C, il le compilera en C++ et puis voilà ;
• ne pas me soucier de la possibilité d'écrire des modules dans d'autres langages, on verra cela plus tard.

Pour l'exécution via navigateur, je pense que je vais plutôt privilégier un "client léger" qui téléchargera les ressources petit à petit.

Donc au final, je vais sûrement continuer en C++, je continue de réfléchir un peu.

Citation:

---

Pour s'en rendre compte, il suffit de télécharger n'importe quel projet open source puis de compiler via MSVS, MinGW et Linux GCC. Deja, il y a de fortes chances que le projet ne compile pas sur les 3 (et je ne parle meme pas des autres compilateurs).

---

Si le code est portable, peut-être à l'exception de quelques petites erreurs, il n'y a pas de raison.

Citation:

---

Ensuite, quand on regarde les sources, il y a des flags sur les compilateurs dans tous les sens, c'est pas évident de savoir quel code est utilisé ou non.

---

Soit tu regardes du code très sale, ce qui est un très mauvais exemple, soit tu regardes des fichiers de bibliothèques standard ou autre qui sont en effet imbuvables.

Citation:

---

Un autre truc qui me gene avec les macros, c'est les comportements différents en fonction de l'ordre des include (en général, une macro redefinit une fonction avec un nom un peu trop générique et ca pete le header suivant).

---

Il y a des conventions pour éviter cela. De plus, en C++, avec les fonctions inline et les variables réellement constantes, l'utilisation de macro est très très rares.

Citation:

---

Quand à la séparation header/implementation, je pense comme Gugelhupf pour les memes raisons. C'est compliqué à lire et ca oblige à passer d'un fichier à l'autre. Et quand on veut modifier le prototype d'une fonction, il faut le faire 2 fois. C'est galère.

---

Compliqué à lire ? Au contraire je trouve.
Pour passer d'un fichier à l'autre, c'est presque automatique. Pour modifier le prototype, un bon IDE modifiera le prototype aux deux endroits.

Citation:

---

Envoyé par Iradrille

Si jamais on doit utiliser des macros, cette une bonne pratique de les undef dès qu'elles ne servent plus.

---

Un gros + :ccool:

Citation:

---

Envoyé par Iradrille

Le RAII (utilisé en interne par std::unique_ptr) résout le problème. ;)

---

Si on part du principe que tous les attributs initialisés dans un constructeur doivent être placé dans un pointeur intelligent, alors beaucoup de pointeurs nus devront être transformés en pointeur intelligent non ?
Je pense qu'il faudrait améliorer le système des pointeurs et constructeurs pour les rendre plus safe, utiliser un moyen détourné qui alourdit la syntaxe (pointeur intelligent), sous prétexte peut-être que cela risquerait autrement d'impacter négativement les performances... Je ne sais pas, il faut juger le pour et le contre, trouver un moyen d'optimiser cet ensemble.

Citation:

---

Envoyé par Neckara

• std::string pour afficher une classe, en Java il faut appeler une méthode ToString() ;

---

On peut redéfinir la méthode toString(), sans forcément avoir besoin de l'appeler explicitement : System.out.println(monObjetQuiRedefinitToString);

Citation:

---

Envoyé par Neckara

Donc tu ouvres et tu ferme ta base de donnée à chaque requête pour utiliser la ressource au sein d'un même bloc ? :aie: (ok, je troll)

---

Oui et non, je me sers d'un pool donc la connexion n'est pas fermée.
Je ne me rappel plus d'avoir vu un standard équivalent à l'API JDBC en C++, donc à part utiliser des API en C tous différents en fonction du SGBD :aie: (j'ai aussi trollé)
Bon blague à part, on peut voir sur isopp qu'un SG11 – Databases Discussion of database-related library interfaces for C++ est toujours en discussion. Mais ça fait un peu tard.

Citation:

---

Envoyé par Neckara

A la fin du bloc, pourquoi pas, mais est-ce que ceci marche aussi lors de la destruction de la classe ? Est-on sûr que finally sera appelé ?

---

C'est un peut comme le RAII, qu'est-ce qui m'assure que mon destructeur sera appelé ?
Le finally sera appelé même si tu as un return dans ton bloc try. Par contre si tu fais un exit de façon explicite, non il ne sera pas appelé.

Citation:

---

Envoyé par Neckara

Je ne suis pas vraiment convaincu, la fenêtre doit prendre quand même pas mal de place si le prototype d'une méthode est un peu longue et a des throws.

---

Peut-être, mais c'est ce que commence à faire le C++ en ajoutant des mot-clés comme final et override afin de rendre plus explicite le code.

Citation:

---

Envoyé par Iradrille

Mais ça ne rend pas le code dur à maintenir ?

---

La signature de la méthode parente est censée indiquer toutes les exceptions qu'elle est susceptible de lancer, ainsi que ses implémentations.
L’implémentation, peut lancer moins d'exception, mais pas d'exception supplémentaire.
Si durant la phase de développement tu t’aperçois du fait que durant la phase de conception tu as oublié d'ajouter une exception dans la signature de la méthode parente, il est possible d'ajouter cet exception dans la signature de la méthode parente. Ça ne "cassera" pas le programme.



J'ai regroupé le thème lié à la gestion des exceptions :

Citation:

---

Envoyé par Neckara

• bool pour voir s'il n'y a pas eu d'erreur (ex, lecture de fichier)

---

Pour les erreurs, c'est du try/catch avec IOException. On ne va pas se servir d'un bool pour dire "false" lorsque chose ne va pas bien (on n'est plus en C), ici on peut donner plusieurs raisons au problème survenu.

Citation:

---

Envoyé par Neckara

Ensuite, c'est avant tout à l'appeleur de vérifier qu'il envoie bien des données valides, donc en théorie de try/catch devrait être inutile.

---

Je ne crois pas que ce soit aussi simple. Quand tu développes une application, tu ne connais pas forcément l'implémentation des API externes. Donc comment savoir à l'avance les types d'erreurs que tu pourrais avoir ? Et même si tu les connaissais et que tu avais dix types d'exception à vérifier, exécuter 10 if avec une fonction booléenne ce n'est pas très propre.

Citation:

---

Envoyé par Neckara

C'est simple, on évite de lancer des exceptions dans un constructeurs. :mouarf:
Si la construction peut échouer, soit on passe par une factory, soit on passe par une méthode MaClasse::create(), soit on donne une fonction pour vérifier la cohérence de la classe.

---

Mon pneu est sous gonflé, mais comme j'ai la flemme d'aller à la station, je vais forcer avec ma pompe à vélo :ptdr:
Éviter volontairement de lancer des exceptions dans un constructeur... c'est un peu dommage non ?

Citation:

---

Envoyé par Gugelhupf

Si on part du principe que tous les attributs initialisés dans un constructeur doivent être placé dans un pointeur intelligent, alors beaucoup de pointeurs nus devront être transformés en pointeur intelligent non ?

---

Sûrement pas, il n'est pas utile d'utiliser un pointeur pour chaque attributs, d'ailleurs, je pense qu'on utilise assez peu de pointeurs en C++ dans les attributs des classes.

Citation:

---

qui alourdit la syntaxe (pointeur intelligent)

---

On a des typedef.

Citation:

---

sous prétexte peut-être que cela risquerait autrement d'impacter négativement les performances...

---

Je ne comprend pas le sens de ta phrase.

Citation:

---

On peut redéfinir la méthode toString(), sans forcément avoir besoin de l'appeler explicitement : System.out.println(monObjetQuiRedefinitToString);

---

Parce que println prend un Object et appelle lui-même toString().

Citation:

---

donc à part utiliser des API en C tous différents en fonction du SGBD :aie: (j'ai aussi trollé)

---

Il y a beaucoup d'API en C++. Sinon il me semble que Qt fournit une interface permettant de se connecter à pas mal de SGBD, je me demande si boost n'en fait pas de même d'ailleurs.

Citation:

---

C'est un peut comme le RAII, qu'est-ce qui m'assure que mon destructeur sera appelé ?

---

Le destructeurs sera forcément appelé avec le RAII, c'est d'ailleurs sont but.

Citation:

---

Peut-être, mais c'est ce que commence à faire le C++ en ajoutant des mot-clés comme final et override afin de rendre plus explicite le code.

---

Oui et ?
Je parle de la fenêtre listant les membres qui devrait être assez grosse, pas du langage Java.

Citation:

---

Pour les erreurs, c'est du try/catch avec IOException. On ne va pas se servir d'un bool pour dire "false" lorsque chose ne va pas bien (on n'est plus en C), ici on peut donner plusieurs raisons au problème survenu.

---

Ce n'est pas parce que tu retournes un booléen en cas d'erreurs que tu ne peux pas récupérer la description de l'erreur...

Et ce n'est pas parce qu'on a des exceptions, qu'il faut les utiliser à tout va.
Les cas d'exceptions doivent rester "exceptionnels". Si c'est une "erreur fréquente", utiliser une exception est incohérent.

En plus utiliser des exception à tout va, c'est lourd pour pas grand chose, surtout quand on peut traiter l'erreur directement.

Citation:

---

Quand tu développes une application, tu ne connais pas forcément l'implémentation des API externes

---

????? On s'en moque de l'implémentation, ce qu'il nous faut c'est le prototype qui nous donne déjà des indications sur les valeurs acceptées.

Citation:

---

Et même si tu les connaissais et que tu avais dix types d'exception à vérifier, exécuter 10 if avec une fonction booléenne ce n'est pas très propre.

---

??????

Citation:

---

Mon pneu est sous gonflé, mais comme j'ai la flemme d'aller à la station, je vais forcer avec ma pompe à vélo :ptdr:

---

??????

Citation:

---

Éviter volontairement de lancer des exceptions dans un constructeur... c'est un peu dommage non ?

---

J'ai rien dit, le C++ disposerais d'une syntaxe pour lancer les exceptions proprement à partir du constructeur :

Citation:

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

A::A() throw (int) try { pBuffer = NULL; pData = NULL; cout << "Début du constructeur" << endl; pBuffer = new char[256]; cout << "Lancement de l'exception" << endl; throw 2; // Code inaccessible : pData = new int; } catch (int) { cout << "Je fais le ménage..." << endl; delete[] pBuffer; delete pData; }

---

---

Et le destructeur ne sera jamais appelé.

Comme quoi j’apprends encore des choses ^^.

Citation:

---

Envoyé par Gugelhupf

Si on part du principe que tous les attributs initialisés dans un constructeur doivent être placé dans un pointeur intelligent, alors beaucoup de pointeurs nus devront être transformés en pointeur intelligent non ?
Je pense qu'il faudrait améliorer le système des pointeurs et constructeurs pour les rendre plus safe, utiliser un moyen détourné qui alourdit la syntaxe (pointeur intelligent), sous prétexte peut-être que cela risquerait autrement d'impacter négativement les performances... Je ne sais pas, il faut juger le pour et le contre, trouver un moyen d'optimiser cet ensemble.

---

Oui, mais en C++ on choisi où l'on à besoin de créer ses objets (pile ou tas). On peut souvent utiliser la pile (sans new, donc sans possibilité de fuite mémoire).
Mais de manière générale oui, une classe gérant des ressources qu'elle alloue sur la pile (avec un new donc) utilisera des pointeurs intelligents.
Le coût d'un std::unique_ptr est nul : aucun impact sur les performance par rapport à un pointeur nu.
Un std::shared_ptr par contre à un coût : le comptage de référence, c'est pas gratuit. Après que ce coût soit négligeable ou pas et dépend vraiment du cas d'utilisation.

Personnellement ça ne me dérange pas les new dans un constructeur, même sans pointeur intelligent : si le new échoue et throw (il éxiste une version nothrow d'ailleurs :)), le programme ne pourra de toute façon plus continuer par manque de mémoire, donc risque de fuite mémoire ou pas, c'est la merde.

Citation:

---

Envoyé par Gugelhupf

C'est un peut comme le RAII, qu'est-ce qui m'assure que mon destructeur sera appelé ?

---

La norme :D

Citation:

---

Envoyé par Gugelhupf

La signature de la méthode parente est censée indiquer toutes les exceptions qu'elle est susceptible de lancer, ainsi que ses implémentations.
L’implémentation, peut lancer moins d'exception, mais pas d'exception supplémentaire.
Si durant la phase de développement tu t’aperçois du fait que durant la phase de conception tu as oublié d'ajouter une exception dans la signature de la méthode parente, il est possible d'ajouter cet exception dans la signature de la méthode parente. Ça ne "cassera" pas le programme.

---

Les indications de throw ne sont donc pas obligatoires ?
Je trouve d'ailleurs l'approche de C++ plus propre la dessus (depuis C++11) : au lieu d'indiquer quelles exceptions une fonction peut lancer, on indique qu'une fonction ne peut en aucun cas lancer d'exceptions.

Salut,


Juste quelques petites remarques en passant :

Citation:

---

Envoyé par Iradrille

Venant du C++, les generics (Java ou C#) c'est vraiment le gros point noir de ces langages, le fait de devoir définir des interfaces limite vraiment l'utilisation.
(En tout cas, c'est ce qui me dérange le plus).

---

Il n'y a aucune obligation de définir des interfaces pour utiliser les Generics...

Citation:

---

Envoyé par Gugelhupf

Ouvrir en lecture et ouverture en même temps, non je ne crois pas, d'ailleurs, si cette possibilité n'est pas fournit, c'est qu'il doit forcément y avoir une raison.

---

Il est tout à fait possible d'ouvrir un fichier à la fois en lecture ET en écriture, via la classe RandomAccessFile disponible depuis Java 1.0 !

Citation:

---

Envoyé par Iradrille

Les indications de throw ne sont donc pas obligatoires ?

---

Cela dépend.
Il y a deux types d'exceptions en Java.

Par défaut les exceptions sont "checked", et une méthode qui peut renvoyer une telle exception doit impérativement l'indiquer via throws dans sa signature, ce qui obligera à la traiter lorsqu'on utilisera la méthode.

Mais il existe également des exceptions "unchecked" (RuntimeException, Error) qui n'ont pas besoin d'être déclarée ni traitée.
C'est toujours bien de les déclarer (pour la doc), mais cela n'aura aucun impact.


a++

Citation:

---

Envoyé par adiGuba

Il n'y a aucune obligation de définir des interfaces pour utiliser les Generics...

---

J'ai toujours cru qu'il n'y avait pas de duck typing en Java.
Quelque chose comme ça est possible ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

template <class T> struct CompareParFoo { bool operator()(T lhs, T rhs) const { return lhs.foo() < rhs.foo(); } };   template <class T, class Predicat> T min(T lhs, T rhs, Predicat pred) { return pred(lhs, rhs) ? lhs : rhs; }   struct UnType { int val; int foo() const { return val; } };   UnType a{1}, b{2}; auto min_ab = min(a, b, CompareParFoo());

---

edit : Ça me fait penser à un autre défaut de Java : le "tout-objet" qui empêche de définir des fonctions libres.
Dès que je dois coder en Java / C#, je me retrouve avec une classe non destinée à être instanciée (statique en C#, souvent avec un nom stupide type "FreeFunctions") qui ne contient que des fonctions statiques (que j'aurais déclarées comme fonctions libres en C++).
Ça indique un problème de conception ? Ou c'est quelque chose de commun ?

Je vous trouve un peu dur concernant la syntaxe de Java.
Rien n'empêche en C++ d'abuser du mot-clé const dans le prototype d'une fonction (au moins deux par pointeur, pour chaque paramètre et type de retour), d'utiliser des macros, ou faire un goto. Un mal pour un bien, en Java vous ne pourrez pas.


Chaque langage possède sa philosophie, et de nouvelle naissent lorsqu'un nouveau besoin apparait (je pense surtout à des langages comme Dart ou Typescript).
Si vous estimez que l'approche des exceptions ou autre fonctionnalité en Java est mauvaise, ou que vous préférez adopter une autre manière, rien ne vous en empêche. Vous pouvez par exemple écrire vos API (en utilisant JNI), avec des fonctions systèmes en C, pour ensuite les utiliser en Java de manière transparente. Plus de try/catch.
Ce n'était amha pas quelque chose d'impossible à faire en Java, mais cela ne doit surement pas faire parti de la philosophie.


Le C++ a donné naissance à la plupart des langages OO que nous utilisons, mais sans les langages comme Smalltalk ou C, il n'en serait pas ainsi.
Les mot-clés comme final et override (dont je parle juste au dessus), ou d'autres concepts comme les templates, et depuis récemment les lambdas, le range-based for loop et délégation du constructeur ne sont pas apparu par magie en C++. Il suffit de voir la syntaxe, et leur période d'apparition.
Ce n'est pas par hasard non plus que les concepteurs de Java voie d'un bon oeil la gestion de mémoire en C11 et C++11 pour l'adapter au Java (voir article).
Chacun pique une idée à droite à gauche.
Si demain la syntaxe des exceptions se retrouvaient simplifié, parce que je ne trouve pas qu'ils le sont (et consommant moins de ressource au passage), et que Bjarne ou autre personnalité incitait les développeurs à l'adopter, je suis sur que vous changerez d'idée ^^. Mais bon pour une moi une exception n'est pas quelque chose qu'on devrait utiliser rarement, là c'est comme si vous demandiez à un développeur Assembleur de ne pas faire de goto/jump.


Merci pour l'info adiGuba :ccool: Par contre je n'ai pas l'impression que ce soit une classe très utilisée en Java :aie:


EDIT :
@Iradrille

Citation:

---

Ça me fait penser à un autre défaut de Java : le "tout-objet" qui empêche de définir des fonctions libres.

---

Il y a les classes anonymes, et depuis Java 8, les lambdas.

Citation:

---

Envoyé par Gugelhupf

Je vous trouve un peu dur concernant la syntaxe de Java.

---

Énormément de dev C++ (moi y compris) feront des remarques sur les exceptions et l'héritage.
Tout simplement parce que ce n'est pas dans la philosophie du C++ de les utiliser autant.

Un exemple simple, si j'utilise une fonction qui peut lancer une exception si les arguments sont invalides, mais que je sais que les arguments sont valides (codés en dur, ou vérification de validité déjà faite), bah j'ai pas envie de me faire ch*** avec un try-catch.

Citation:

---

Envoyé par Gugelhupf

Rien n'empêche en C++ d'abuser du mot-clé const dans le prototype d'une fonction (au moins deux par pointeur, pour chaque paramètre et type de retour), d'utiliser des macros, ou faire un goto. Un mal pour un bien, en Java vous ne pourrez pas.

---

De la même manière on peut abuser du mot clef final pour les paramètres d'une fonction. ;)

Mais si on va par là, il est évident que si on cherche à faire du code crade, on y arrivera, et ce, quelque soit le langage.

Citation:

---

Envoyé par Gugelhupf

Il y a les classes anonymes, et depuis Java 8, les lambdas.

---

Dac, je connaissais pas. ;)

Citation:

---

Envoyé par Gugelhupf

Rien n'empêche en C++ d'abuser du mot-clé const dans le prototype d'une fonction (au moins deux par pointeur, pour chaque paramètre et type de retour)

---

Abuser de const ? :koi:

Citation:

---

d'utiliser des macros, ou faire un goto. Un mal pour un bien, en Java vous ne pourrez pas.

---

goto n'a effectivement pas de sens en Java puisque vous utiliserez des exceptions à la place et que vous ne pouvez pas faire des programmes avec des contrainte temporelles très fortes dans quel cas on passera soit vers du C++, du C ou directement de l'assembleur.

Pour les macro, il est vrai qu'avec les fonctions-inlines, les templates/generics et les enum/constantes, elles sont un peu moins utilisée.
Par contre, je ne pense pas qu'en Java, vous puissiez passer des options au "compilateur" qui changeraient le comportement du code ce qui est possible grâce aux macro (debug/release, utiliser telle ou telle bibliothèque, intégrer telle ou telle fonctionnalité, etc.).

Citation:

---

Chacun pique une idée à droite à gauche.

---

Et alors ?


@Gugelhupf : on ne dit pas "pouah ! Le Java c'est nul !".
J'ai juste dit que je ne portais pas le Java dans mon cœur, ce qui est tout à fait mon droit, et comme tu voulais savoir pourquoi je t'ai répondu et on a commencé à débattre autours de ces points.
Mais là j'ai l'impression que tu commences à te placer dans une logique "il faut défendre Java, j'enfile mon armure pour rejoindre la croisade", alors qu'on ne l'attaque pas.

Bref, je pense qu'il vaut mieux s'arrêter là, sinon on va partir en guerre de religion.

Citation:

---

Envoyé par Neckara

Abuser de const ? :koi:

---

Code:

---

1 2 3

int const * const * const * const fonctionRelou(int const * const * const * const arg) { return arg; }

---

Ce n'est pas de l'abus en soit si c'est justifié, mais ça peut devenir lourd.

Il y a un dév du nom shakal sur le SdZ qui a développé un jeu 3D du nom de Yildiz Online, avec un mélange de Java et C++, en se servant de OpenGL il me semble.
Tu pourrais lui poser des questions peut-être ;)

Citation:

---

Envoyé par Gugelhupf

Il y a un dév du nom shakal sur le SdZ qui a développé un jeu 3D du nom de Yildiz Online

---

Je connais, il est aussi sur DVP : http://www.developpez.net/forums/d12...ueur-l-espace/

Citation:

---

avec un mélange de Java et C++, en se servant de OpenGL il me semble.
Tu pourrais lui poser des questions peut-être ;)

---

Je n'avais pas vu qu'il mélangeais les deux, je vais essayer de regarder cela de plus près :ccool:

Citation:

---

Envoyé par Iradrille

J'ai toujours cru qu'il n'y avait pas de duck typing en Java.

---

Non en effet il n'y a pas de duck typing en Java (en fait j'avais mal compris ton premier message).

Après est-ce une mauvaise chose ? Je ne sais pas et la différence se joue à peu de chose :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

public <T extends Comparable<T>> T min(T value1, T value2) { return (value1.compareTo(value2) >=0) ? value1 : value2; }       class UnType implements Comparable<UnType> { int val; int foo() { return this.val; }   @Override public int compareTo(UnType other) { return Integer.compare(this.val, other.val); } }

---

Perso j'ai tendance à largement préféré les typage fort à un typage implicite.
Mais au final ce n'est juste qu'une question de syntaxe...

Citation:

---

Envoyé par Iradrille

edit : Ça me fait penser à un autre défaut de Java : le "tout-objet" qui empêche de définir des fonctions libres.
Dès que je dois coder en Java / C#, je me retrouve avec une classe non destinée à être instanciée (statique en C#, souvent avec un nom stupide type "FreeFunctions") qui ne contient que des fonctions statiques (que j'aurais déclarées comme fonctions libres en C++).
Ça indique un problème de conception ? Ou c'est quelque chose de commun ?

---

Non c'est commun.
Souvent on utilise une classe dont le nom informe sur le type manipulé (par exemple les méthodes static manipulant des Date se trouveront dans la classe Dates).

Ce n'est certainement pas parfait (et je n'ai pas vu de solution parfaite pour cela), mais je ne trouve pas cela pire que d'avoir des méthodes définies un peu partout...

Citation:

---

Envoyé par Neckara

Par contre, je ne pense pas qu'en Java, vous puissiez passer des options au "compilateur" qui changeraient le comportement du code ce qui est possible grâce aux macro (debug/release, utiliser telle ou telle bibliothèque, intégrer telle ou telle fonctionnalité, etc.).

---

C'est pourtant possible !
Pas au compilateur javac, mais au compilateur JIT à l'exécution via l'option -D !
Et oui il ne faut pas oublier que toutes les optimisations du compilateur sont effectué par le compilateur JIT.

Exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10

public class Main { private static final boolean IS_DEBUG_ENABLED = Boolean.getBoolean("DEBUG");   public static void main(String[] args) { System.out.println("Hello"); if (IS_DEBUG_ENABLED) { System.out.println("World"); } } }

---

:arrow: java Main affichera "Hello"
:arrow: java -DDEBUG=true Main affichera "Hello World"

Si tout le code sera bien stocké dans le fichier *.class avec le passage par le compilateur javac, il sera toutefois bien supprimé à l'exécution si le flag est absent.

Citation:

---

Envoyé par Neckara

Bref, je pense qu'il vaut mieux s'arrêter là, sinon on va partir en guerre de religion.

---

Java et C++ adapte tout deux une approche très différente de la POO... et il peut être difficile de passer de l'un à l'autre lorsqu'on est habitué à travailler avec l'un.

Mais ce n'est pas pour autant qu'il y en a un meilleur que l'autre.
Si tu prend les fonctionnalités différentes une à une, tout est ouvert à discussion, et chaque solution est tout à fait viable (sinon ce ne serait pas deux langages aussi utilisés).
Chaque choix a ses raisons, ses points forts et ses défauts... le tout suivant l'historique du langage.

Le problème c'est lorsqu'on passe de l'un à l'autre, on à tendance à apporter toute son expérience et ses habitudes avec soit (volontairement ou pas).
Bref de faire du C++ en Java, ou de faire du Java en C++. Et là ce n'est généralement vraiment pas adapté !


a++

Citation:

---

Envoyé par adiGuba

Mais ce n'est pas pour autant qu'il y en a un meilleur que l'autre.

---

Je n'ai jamais dit cela, juste que je ne portais pas Java dans mon cœur.

Citation:

---

Chaque choix a ses raisons, ses points forts et ses défauts... le tout suivant l'historique du langage.

---

Ce qui ne nous empêche pas d'avoir notre propre avis concernant ces choix.
C'est d'ailleurs grâce à cela qu'on peut comprendre un peu mieux la philosophie du langage et comprendre ses nuances.

Citation:

---

Envoyé par Neckara

Je n'ai jamais dit cela, juste que je ne portais pas Java dans mon cœur.

---

Je ne te visais pas, ni personne en particulier (désolé si tu t'es senti visé ce n'était pas du tout le cas).

En fait je te rejoignais juste sur le fait que ce genre de discussion part vite "en guerre de religion", justement à cause de préférence personnelle...
Je suis juste intervenu sur un ou deux erreurs qu'il me semblait avoir vu.


Ce genre de discussion peut être intéressante si on compare vraiment les fonctionnalités en analysant les qualités et leurs défauts, sans émettre de jugement de valeurs personnel... mais ce n'est pas évident !


a++

Citation:

---

Envoyé par adiGuba

Non en effet il n'y a pas de duck typing en Java (en fait j'avais mal compris ton premier message).

Après est-ce une mauvaise chose ? Je ne sais pas et la différence se joue à peu de chose

---

Ça à ses avantages et ses inconvénients.
Ça évite de se taper des centaines de lignes d'erreurs pour une faute de frappe (comment ça se fait que personne n'en ai parlé ? :aie:), mais ça crée de l'héritage artificiel et relativement inutile.

Après je comprend bien que des templates (type C++) en Java sont impossibles du fait que le Java permette la "création" de nouveaux type durant l’exécution (chargement dynamique de .class par exemple), ce qui rend impossible le duck typing, il faut une interface commune pour s'assurer que le type passé à une classe / méthode template soit valide.

D'ailleurs si j'ai bien compris le système de "concept" qui devrait arriver avec C++14, ça se rapproche un peu de ce que fait Java : imposer des contraintes précises sur le type template, mais avec une différence : les contraintes ne seront pas garanties via l'héritage. (Toujours pareil, les templates sont résolus lors de la compilation en C++, pas besoin d'interface commune).

Citation:

---

Envoyé par Iradrille

Ça à ses avantages et ses inconvénients.
Ça évite de se taper des centaines de lignes d'erreurs pour une faute de frappe (comment ça se fait que personne n'en ai parlé ? :aie:), mais ça crée de l'héritage artificiel et relativement inutile.

---

Je n'ai pas l'habitude des Templates de C++, mais avec les Generics on a pas de "centaines de lignes d'erreurs pour une faute de frappe".

Par contre il est vrai que certaines erreurs sont difficilement compréhensible et que cela peut ne pas être très clair du tout à comprendre.

Citation:

---

Envoyé par Iradrille

Après je comprend bien que des templates (type C++) en Java sont impossibles du fait que le Java permette la "création" de nouveaux type durant l’exécution (chargement dynamique de .class par exemple), ce qui rend impossible le duck typing, il faut une interface commune pour s'assurer que le type passé à une classe / méthode template soit valide.

---

Je ne pense pas que cela soit techniquement impossible.
C'est plutôt une question de philosophie : en Java on fait cela en utilisant une interface explicitement, c'est tout.

Il n'y a pas de raison de vouloir le faire différemment.

Citation:

---

Envoyé par Iradrille

D'ailleurs si j'ai bien compris le système de "concept" qui devrait arriver avec C++14, ça se rapproche un peu de ce que fait Java : imposer des contraintes précises sur le type template, mais avec une différence : les contraintes ne seront pas garanties via l'héritage. (Toujours pareil, les templates sont résolus lors de la compilation en C++, pas besoin d'interface commune).

---

Je dirais que cela montre une approche différente de la POO.
Contrairement à C++, Java est très axé sur l'héritage et les méthodes virtuelles, avec une pelletée d'interface décrivant plusieurs comportements, donc c'est tout naturellement que ceci est utilisé pour les Generics et d'autres choses (comme les lambda dans Java 8).

A l'inverse en C++ on s'orientera plus vers la présence (ou non) de méthodes spécifiques pour décrire un comportement, d'où le duck typing entre autres...



a++

Citation:

---

Envoyé par adiGuba

Je n'ai pas l'habitude des Templates de C++, mais avec les Generics on a pas de "centaines de lignes d'erreurs pour une faute de frappe".

Par contre il est vrai que certaines erreurs sont difficilement compréhensible et que cela peut ne pas être très clair du tout à comprendre.

---

Je parlais bien évidement des erreurs en C++. ;)

Code:

---

1 2 3 4 5 6 7 8 9

#include <set>   struct Foo { }; // opérateur< manquant.   int main() { std::set<Foo> test; test.insert(Foo()); return 0; }

---

Donne

Code:

---

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

1>C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xstddef(180): error C2676: binary '<' : 'const Foo' does not define this operator or a conversion to a type acceptable to the predefined operator 1> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xstddef(179) : while compiling class template member function 'bool std::less<_Kty>::operator ()(const _Ty &,const _Ty &) const' 1> with 1> [ 1> _Kty=Foo 1> , _Ty=Foo 1> ] 1> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xtree(1792) : see reference to function template instantiation 'bool std::less<_Kty>::operator ()(const _Ty &,const _Ty &) const' being compiled 1> with 1> [ 1> _Kty=Foo 1> , _Ty=Foo 1> ] 1> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\type_traits(743) : see reference to class template instantiation 'std::less<_Kty>' being compiled 1> with 1> [ 1> _Kty=Foo 1> ] 1> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\xtree(1028) : see reference to class template instantiation 'std::is_empty<std::less<_Kty>>' being compiled 1> with 1> [ 1> _Kty=Foo 1> ] 1> C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\set(44) : see reference to class template instantiation 'std::_Tree<std::_Tset_traits<_Kty,_Pr,_Alloc,false>>' being compiled 1> with 1> [ 1> _Kty=Foo 1> , _Pr=std::less<Foo> 1> , _Alloc=std::allocator<Foo> 1> ] 1> main.cpp(6) : see reference to class template instantiation 'std::set<Foo,std::less<_Kty>,std::allocator<_Kty>>' being compiled 1> with 1> [ 1> _Kty=Foo 1> ]

---

Ça reste ici relativement explicite (voir la première ligne de l'erreur), mais c'est affreusement long, et c'est rare d'avoir une erreur aussi claire avec un problème de template.

Les messages d'erreurs de compilations non-explicites ne sont pas intrinsèque au langage mais au compilateur utilisé.

En C++ par exemple, Clang a la réputation de donner des messages d'erreurs plus explicites.

Citation:

---

Envoyé par Neckara

Si le code est portable, peut-être à l'exception de quelques petites erreurs, il n'y a pas de raison.

---

Pour l'instant, avant de casser du code c++ open source avec mes vieux reflexes de Javateux, je me contente de jouer avec les makefiles. Et quand je parlais des différences qui font qu'un code compile ou non, j'ai juste remarqué que certains headers sont importés ou non selon le compilateur. Par exemple, j'ai vu plusieurs fois du code qui ne compile pas avec MinGW parce que <sys/types.h> n'est pas importé mais qui compile avec gcc (surement parce qu'il est inclus ailleurs). Et ca, du point de vue du developpeur, j'aurais aimé ne pas avoir à m'en soucier. Si un code compile avec MinGW, je m'attends à ce qu'il compile avec n'importe quel compilateur qui respecte la meme norme. Hors, ce n'est pas le cas.

Citation:

---

Envoyé par Neckara

Soit tu regardes du code très sale, ce qui est un très mauvais exemple, soit tu regardes des fichiers de bibliothèques standard ou autre qui sont en effet imbuvables.

---

Comme je l'ai dit, je joue avec les makefiles donc je suis amené à regarder pourquoi j'ai des erreurs de compilation différentes selon les compilateurs. Et ca vient souvent des bibliotheques standard. Et je confirme que c'est imbuvable :)