Discussion :

[atha2]

Bonjour,
étant développeur Java, j'ai envie de me mettre au c++ (j'ai déjà lu quelques tutoriels et je pense maitriser les bases du langage).

Je voudrais quelques conseils/précisions :

1. J'ai entendu qu'il y avait plusieur norme C++, la norme M$ et la norme ANSI-C++ et probablement d'autres. Qu'en est-il exactement à quoi ça correspond (compilateurs différents, règles à respecter..). J'avoue que je suis en peu perdu dans tout ça.
2. En rapport avec la question précédente, quelle EDI me conseillé vous ?( VS2008, CodeBlock, NetbeansC/C++, autres ...)
3. Je me demandais quelles bibliothèque puis-je utilisé pour les collections, gestion des threads , GUI ... (existe-t'il un équivalent du JDK ?)
4. Gestion des headers :
   • j'ai vu que l'on ne devait définir dans l'entête que le prototype de la classe (attribut, déclaration de méthode) et que le code des fonctions devait être déclaré dans un fichier propre à chaque fonction
   • Ceci s'applique-t'il méthode suivante :
     • constructeur(par défaut, par copie)
     • destructeur
     • redéfinition d'opérateur
     • getteur/setteur
   • Sachant que ces derniers(getteur/setteur) doivent être déclaré inline cela oblige-t'il à les coder dans le header ?

Je développe sous Windows Vista/Ubuntu et utilise actuellement gcc/g++ via cygwin

Merci d'avance à celui/celle/ceux qui prendront le soin de se pencher sur mes interrogations

[3DArchi]

• En rapport avec la question précédente, quelle EDI me conseillé vous ?( VS2008, CodeBlock, NetbeansC/C++, autres ...)

Moi j'utilise indifféremment Eclipse CDT, DevC++ et Visual. Affaire de gout et d'habitude. Le premier est un peu lourd mais en venant du monde java peut-être le connais-tu déjà, le second est un peu plus léger mais je le trouve parfois pas très pratique et le dernier est assez bien pour le debug.

• Je me demandais quelles bibliothèque puis-je utilisé pour les collections, gestion des threads , GUI ... (existe-t'il un équivalent du JDK ?)

MFC mais c'est uniquement Windows et un peu lourd.
wxWidget.
D'autres te parleront mieux que moi de choses comme QT.

[LIST][*]Gestion des headers :

• j'ai vu que l'on ne devait définir dans l'entête que le prototype de la classe (attribut, déclaration de méthode) et que le code des fonctions devait être déclaré dans un fichier propre à chaque fonction

Un header pour la définition de la classe un cpp pour son implémentation. C'est une bonne pratique même si cela n'a rien d'obligatoire.

• Ceci s'applique-t'il méthode suivante :
  • constructeur(par défaut, par copie)
  • destructeur
  • redéfinition d'opérateur
  • getteur/setteur
• Sachant que ces derniers(getteur/setteur) doivent être déclaré inline cela oblige-t'il à les coder dans le header ?

Oui pour tout. Pour les getteur/setteur comme en général ils sont relativement simples, on les définie directement dans la déclaration de la classe.

[nikko34]

[*]J'ai entendu qu'il y avait plusieur norme C++, la norme M$ et la norme ANSI-C++ et probablement d'autres. Qu'en est-il exactement à quoi ça correspond (compilateurs différents, règles à respecter..). J'avoue que je suis en peu perdu dans tout ça.

Officiellement il n'y en a qu'une et la dernière version de la norme date de 2003. L'ancienne norme datait de 1998. Il se peut que tu ais entendu ça parce que certains compilateur comme VisualC++ 6 datent d'avant 1998.

[*]Je me demandais quelles bibliothèque puis-je utilisé pour les collections, gestion des threads , GUI ... (existe-t'il un équivalent du JDK ?)

En standard tu as la Standard Library qui contient un ensemble de collections et autres ( string etc.. ) qu'il faut savoir utiliser.

Ensuite, tu as Boost qui est un ensemble de bibliothèques pour le C++ dont une partie fera partie du prochaine standard.

Ensuite si tu es sous windows, il y a des librairies spécial windows ( comme MFC etc.. ). Si tu es sous Linux, tu auras aussi des fonctions différentes. L'essentiel en apprenant le C++ est de bien comprendre ce qui est du C, ce qui est de l'API propre à l'OS, ce qui est du C++ standard.

Pour les bibliothèques graphiques, il y en a beaucoup au choix, mais une des plus connues et utilisées est Qt.

[*]Gestion des headers :[LIST][*]j'ai vu que l'on ne devait définir dans l'entête que le prototype de la classe (attribut, déclaration de méthode) et que le code des fonctions devait être déclaré dans un fichier propre à chaque fonction

Eh ben ça dépend. Tu peux définir toutes tes fonctions inline si tu veux dans le .h ( mais ce n'est pas conseillé ). Quand tu utilises les templates, tu es aussi obligé de définir test fonctions les utilisant dans ton .h.

Généralement pour une classe on utilise un fichier .h avec les déclarations + fonctions inline et un fichier .cpp avec les définitions des méthodes + fonctions outils.

[Frifron]

Sinon pour le passage java a C++, il faut bien étudier les différences dans le langage en lui même. Il y a quelques subtile différences qui peuvent amener des erreurs :

• une méthode est virtuelle par défaut en java (sinon il faut préciser final). C'est le contraire en C++
• Le polymorphisme ne s'effectue que sur des pointeurs ou des références
• Bien voir les valeurs/références/pointeur, c'est une différence majeur avec le JAVA ou tout objet est une référence. Le new ne s'utilise pas de la meme facon qu'en JAVA
• L'accessibilité par défault en java est package, en C++ c'est privée
• D'ailleurs l'accessibilité package n'existe pas en C++. Mais il y a le concept de friend
• L'héritage multiple existe en C++
• ...

[loufoque]

Tu peux programmer en C++ exactement comme en Java.
Néanmoins, ce n'est certainement pas le paradigme conseillé. Je te conseille donc d'apprendre le RAII et tout ça.

[nikko34]

Il faut aussi bien comprendre en C++ ce qu'est une référence et toute la partie const-correctness.

Et aussi les exceptions qui s'utilisent différement, et la partie RAII avec les destructeurs

[Frifron]

Tu peux programmer en C++ exactement comme en Java.

La facon de manier les instances est tout de même différente. Le portage minimum est de remplacer toute les référence JAVA en pointeur C++, ce qui impose de bien gérer ses destructeurs. En C++, il ne faut pas oublier l'allocation statique, qui n'existe pas en JAVA. Il faut aussi faire attention au polymorphisme (en spécifiant bien ses virtual). Et puis, le C++ n'est pas un langage pure OO non plus. Bref coder du C++ comme du JAVA c'est sans doute faisable mais ca donne du code pourri et du coup ce n'est plus vraiment "coder en C++" mais "coder en JAVA en utilisant la syntaxe C++".

Et puis apres il y a le probleme de la librairie standard du C++ nettement moins fourni que celle de JAVA

[nikko34]

La facon de manier les instances est tout de même différente. Le portage minimum est de remplacer toute les référence JAVA en pointeur C++, ce qui impose de bien gérer ses destructeurs.

ben non, le portage minimum c'est de remplacer les références JAVA en références C++

[Frifron]

ben non, le portage minimum c'est de remplacer les références JAVA en références C++

Comment tu fait un new sur une référence C++ ?
Comment tu met une reference C++ à NULL ?
Comment tu stockes des références C++ dans un conteneur ?

[yan]

Comment tu fait un new sur une référence C++ ?
Comment tu met une reference C++ à NULL ?
Comment tu stockes des références C++ dans un conteneur ?

Pour cà, utilise des pointeurs

[Médinoc]

Le problème majeur sur le passage de Java à C++, c'est qu'il n'y a pas de Garbage Collector.

Heureusement, dans la plupart des cas (absence de cycles), on peut compenser avec la classe shared_ptr<> de Boost...
Mais je conseillerais plutôt d'apprendre la gestion de la mémoire et la RAII.

[nikko34]

Ca me rappelle une discussion avec un responsable du développement qui me disait:

"je reconnais les programmeurs qui viennent du JAVA en C++ parce qu'ils mettent des new mais pas de delete"

mais en vérité c'est:

"je les reconnais parce qu'ils mettent des new".

[Médinoc]

Mais même en C++, il y a des choses que tu ne peux faire sans new...

[nikko34]

Mais même en C++, il y a des choses que tu ne peux faire sans new...

oui

[Klaim]

Ca me rappelle une discussion avec un responsable du développement qui me disait:

"je reconnais les programmeurs qui viennent du JAVA en C++ parce qu'ils mettent des new mais pas de delete"

mais en vérité c'est:

"je les reconnais parce qu'ils mettent des new".

C'est tellement vrai!

Je pense que globalement c'est pas une bonne idée de chercher les similarités et différence entre ces deux languages pour pouvoir apprendre rapidement le c++. Les mots n'ont pas le même sens, donc ce qu'il se passe réellement en C++ quand le code s'execute ne corresponds pas ce qu'il se serait passé en JAVA avec les mêmes mots.

Pour moi, un réaprentissage par le vide est nécessaire : revoir exactement la définition, syntaxe, implications, contrats, conséquences de chacune des instructionsdu c++ en oubliant complètement ce qu'on faisait en JAVA.

Et surtout, ne jamais oublier que la plupart du temps, les instructions qu'on donne ont une conséquence "physique" prévisible dans la machine. En java, c'est bien plus flou, sauf si on se base sur ce que fera un compiler en particulier. En c++, c'est tout simplement plus prévisible.

[atha2]

"je les reconnais parce qu'ils mettent des new".

J'avoue être étonné par cette remarque. Dans mon esprit (pervertit par le Java probablement), le C++ était un langage Objet. Si tu pouvais m'éclairait un peu plus sur la bonne démarche à suivre pour réaliser un bon programme en C++.

Je te conseille donc d'apprendre le RAII et tout ça.

Qu'entends tu par "et tout ça" ?

J'ai aussi entendu parler d'allocation statique, j'imagine que c'est tout ce qui est alloué sur la pile (par opposition à celle dynamique (new/malloc ? c'est bien ça ?) qui alloue sur le tas) mais concrètement c'est juste :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int a = 4

non ?

De plus certaine de mes questions sont restées en suspend :

• inline implique t'il forcément défini dans le même fichier ?
• Doit-on définir (écrire le corps de la fonction) les constructeurs ainsi que les destructeurs, redéfinitions d'opérateur ?
• De plus pour la gestion des fichiers :
  • 1 fichier .cpp pour chaque header contenant toutes les définitions de fonction
  • ou 1 fichier .cpp pour chaque fonction.
  Que faut-il faire ?

Merci.

[loufoque]

La facon de manier les instances est tout de même différente. Le portage minimum est de remplacer toute les référence JAVA en pointeur C++, ce qui impose de bien gérer ses destructeurs.

Non non, on peut vraiment coder en C++ comme en Java.
Tu peux utiliser un ramasse-miettes de différentes façons, que ce soit avec des pointeurs intelligents ou avec un ramasse-miettes conservateur.

Mais même en C++, il y a des choses que tu ne peux faire sans new...

Moi j'en mets nulle part [1] (à part quelques placement new dans des briques bas-niveau), je n'utilise d'ailleurs pas de pointeurs non plus.
Ça ne m'a jamais posé de problèmes.

[1] En fait c'est faux, j'ai récemment travaillé sur un ordonnanceur de threads sur machines hierarchiques où je me suis servi de choses similaires à shared_ptr car l'ordonnanceur avait besoin de maintenir en vie des structures créées par des threads qui peuvent mourir à tout moment à cause de la concurrence.
Mais bon le partage dans un environnement concurrent, forcément, ça requiert une durée de vie dynamique.

[Klaim]

J'avoue être étonné par cette remarque. Dans mon esprit (pervertit par le Java probablement), le C++ était un langage Objet. Si tu pouvais m'éclairait un peu plus sur la bonne démarche à suivre pour réaliser un bon programme en C++.

D'abord, le C++ est un language qui permet (entre autre) la programmation objet (l'interet etant de l'utiliser là où c'est efficace, et pas forcément de manière systématique - valable de même pour les autres "techniques").
Ensuite, le fait d'utiliser la programmation objet n'a pas de lien direct avec la façon d'allouer les dits objets.

L'allocation statique... c'est un peu plus large que ça. Globalement tu peux construire tout un système d'objet sans utiliser new SI la quantité de chacun des types d'objets est connu au moment de la compilation (je dis une règle globale, mais je pense qu'il doit y avoir des exceptions...)
La plupart du temps l'utilisation de new n'est nécessaire que dans deux cas : 1) on ne connait le type final de l'objet qu'au runtime 2) on ne connait la quantité d'objets qu'au runtime.

Enfin, il y a beaucoup de choses a dire sur le sujet...

inline implique t'il forcément défini dans le même fichier ?

"inline" est une indication au compilo pour que potentiellement, si c'est pertinent (ou forcé selon les parmettres et mots clés spécifiques utilisés), il copie le contenu de ta methode là où elle est appelé (enfin l'équivalent des instructions disons).

Donc, si tu mets le code dans le header, ta fonction est implicitement inline. Ca ne veut pas dire, comme dit au dessus, qu'elle le sera au final. Certains compilos nécessitent d'ajouter encore l'instruction inline pour que ce soit effectivement le cas; mais c'est souvent juste en Debug ou l'inlining est souvent absent ou mineur.

Pour finir et répondre : non, la définition (le code de la methode) peut être dans un cpp séparé.

Doit-on définir (écrire le corps de la fonction) les constructeurs ainsi que les destructeurs, redéfinitions d'opérateur ?

Je ne comprends pas le sens de cette phrase?

De plus pour la gestion des fichiers :

* 1 fichier .cpp pour chaque header contenant toutes les définitions de fonction
* ou 1 fichier .cpp pour chaque fonction.

Que faut-il faire ?

Il n'y a pas de de chose qu'il "faut" faire. Ya des recommandations dans les cas communs, mais globalement mieu vaut simplement comprendre ce que sont les .h et .cpp et comment ils sont utilisés par le compilateur pour bien les utiliser.

Pour faire simple, dans le cas ultra commun ou je veux faire un nouveau systeme : je me dis que mon systeme va etre constitué par exemple d'un objet manager qui gère d'autres objets, disons des blob. Je compte donc créer deux classes : BlobManager et Blob. Le premier va gérer le second.

Pour cela, niveau fichiers, je vais créer un header et un cpp pour chacun : BlobManager.h qui contiendra donc la déclaration de BlobManager et incluera Blob.h qui contiendra la déclaration de Blob; puis BlobManager.cpp contiendra le code de BlobManager pour manipuler des Blobs et incluera Blob.h histoire de savoir ce qu'on manipule, et bien evidemment BlobManager.h.

Maintenant, imaginons qu'en ecrivant le code de Blob, je me dise que c'est une classe qui se résume principalement a un petit aglomérat de données et d'une fonction avec deux lignes d'instructions. Je me dit qu'il est inutile de faire un cpp pour juste une "représentation" de données qui n'a pas vraiment de fonction autre que celles de constructions et de destruction.
Donc, je vire Blob.cpp, qui est inutile.

Comme tu peux le voir, j'aurais pu suivre une règle simple : Pour une classe A, je crée A.h et A.cpp, mais dans la pratique ce n'est pas forcément nécessaire.

De même, il arrive souvent que des déclarations soient rassemblées dans des headers sans cpp liés et souvent dans le cas de déclarations partagées par tout le projet.

Je sais pas si je t'ai aidé ou embrouillé, en tout cas là encore mieu vaut de la lecture sur les bases du language pour bien comprendre ce que sont les cpp et h pour jongler habilement avec le compilateur.

[Klaim]

Non non, on peut vraiment coder en C++ comme en Java.
Tu peux utiliser un ramasse-miettes de différentes façons, que ce soit avec des pointeurs intelligents ou avec un ramasse-miettes conservateur.

On peut avoir la meme syntaxe qui fera plus ou moins la même chose dans la théorie, mais dans la pratique on aura pas la même chose.

[loufoque]

Et en quoi ?