Conseil pour passage Java -> C++

Ben les manipulations mémoire ne seront pas les mêmes- donc ça ne fais pas la même chose. Ca peut (je pense pas toujours) donner le même résultat, mais pas de la même façon.

Peut être que c'est pas important pour tout le monde (je pense que la plupart des cas simples, on s'en fou) mais dans toutes les applications que j'ai fait jusqu'ici, même la manière dont on arrive au résultat compte.

Plus globalement je pense que c'est pas une bonne idée de partir d'un language directement en transposant la logique d'un autre. Ca amène quasi directement à de la frustration qui peut couter non seulement du moral mais aussi de la productivité.

(au passage, je vois mal le rapport entre les shared_ptr et le JAVA, il me semble que le garbage collector travaille d'une manière plus subtile et temporisée que ce qu'il se passe avec un shared_ptr - mais faudrait un expert java pour le confirmer :) )

Citation:

---

Envoyé par Klaim

au passage, je vois mal le rapport entre les shared_ptr et le JAVA, il me semble que le garbage collector travaille d'une manière plus subtile et temporisée que ce qu'il se passe avec un shared_ptr - mais faudrait un expert java pour le confirmer

---

Le GC de Java marche comme tout GC... en séparant les objets accessibles de ceux qui ne le sont plus, et sont alors "finalisés"
Ensuite la destruction de l'objet peut passer par plusieurs phases en fonction des references qui trainent dessus (Weak, ...).

Sinon les references vers un objet Java sont exactement comme des shared_ptr. Le "finalize" pouvant être associé au destructeur. A la différence, qu'en C++ l'objet sera détruit dès la perte du dernier shared_ptr, alors qu'en Java, la finalisation peut trainer ad vitam aeternam (rien n'oblige une implémentation java de finaliser les objets d'ailleurs).

Sinon, après, c'est un avis personnel... la programmation Java et la programmation C++ sont très proches... (même si Java est plus proche de C# encore surtout depuis 1.5).
Dans les deux cas il faut bien séparer les "types" (en C++ constructeurs par recopie, definition des opérateurs == etc..., en Java, implémentation de Serializable et Clonable, redéfinition de equals et hashCode, immutabilité et finalisation des methodes) des "objets" (en C++, constructeur par recopie et operateur de copie privés) et les mêmes principes d'algorithmique s'appliquent.

Citation:

---

Envoyé par nicroman

Sinon, après, c'est un avis personnel... la programmation Java et la programmation C++ sont très proches... (même si Java est plus proche de C# encore surtout depuis 1.5).
Dans les deux cas il faut bien séparer les "types" (en C++ constructeurs par recopie, definition des opérateurs == etc..., en Java, implémentation de Serializable et Clonable, redéfinition de equals et hashCode, immutabilité et finalisation des methodes) des "objets" (en C++, constructeur par recopie et operateur de copie privés) et les mêmes principes d'algorithmique s'appliquent.

---

La tu compares une moto à... au moteur d'une voiture, pas à la voiture.

Tu voulais surement comparer la programmation Java et le C++ OO.

En supposant que tu vises juste, on pourrait rapprocher le code de Boost et du code Java ?

La programmation générique prend de plus en plus de place en C++ et ça devrait continuer avec la croissance de Boost et C++0x. Le C++ ce n'est plus juste quelques sucres syntaxiques pour écrire des fonctions templates, de l'OO et des exceptions.

Si tu veux programmer en C++ comme en Java, tu rateras pas mal de choses intéressantes et puissantes.

Pour ce qui est de la gestion des ressources, en effet les smart pointers sont ce qu'il faut pour "ne plus se soucier de la libération des ressources". Sauf qu'effectivement comme dit ci-dessus l'objet est détruit quand il ne sert plus, et non pas quand une machine virtuelle daignera s'en soucier.

Citation:

---

Envoyé par atha2

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++.

---

tu peux écrire ça:

Code:

---

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

void affiche( std::string * uneChaine ) { std::cout << *uneChaine << " , taille: " << uneChaine->length() << std::endl; } //... int main() { std::string * chaine = new string(); affiche( chaine );   delete chaine;   return 0; }

---

alors que le code "normal" en C++ serait:

Code:

---

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

void affiche( const std::string & maChaine ) { std::cout << maChaine << " , taille: " << maChaine.length() << std::endl; } //.. int main() { std::string chaine; affiche( chaine );   return 0; }

---

Pareil dans les classes:

tu peux écrire cela:

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

class MaClasse { public:   /**          * Constructeur.          */ MaChaine( std::string chaine ) { chaine_ = new std::string( chaine ); }   /**          * Destructeur.          */ ~MaChaine() { delete chaine_; }   /**          * Getter          */ std::string * getChaine() { return chaine_; }   private:   std::string * chaine_; };

---

alors que le code classique en C++ serait:

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

class MaClasse { public:   /**          * Constructeur.          */ MaChaine( const std::string & chaine ) : chaine_( chaine ) { }   /**          * Getter          */ const std::string & getChaine() const { return chaine_; }   private:   std::string chaine_; };

---

La deuxième classe se copie sans problème. Une méthode naïve avec la première t'amènera à la catastrophe.

Dans les grosses différences :
- si tu as compris le LSP, l'héritage multiple ne devrait pas poser de problèmes majeurs -- vu que tu ne serais alors pas tenté de l'utiliser à mauvais escient.

- une vraie sémantique de valeur est possible sur les types utilisateurs C++, et combinée avec le polymorphisme paramétrique à la sauce template (qui est plus qu'un sucre syntaxique au dessus d'un void*), plus besoin de se prendre le choux sur comment implémenter equals().

- des données qui ont une allocation stack-based ("statique" me fait plutôt penser à la zone statique de mémoire (i.e. où sont les globales)). C'est le point de départ pour le RAII : permettre de libérer n'importe quelle ressource (mémoire comme pot de peinture) de façon déterministe, implicite, et uniforme. [d'où les remarques sur les shared_ptr<> et autres (indirectement) "les javaistes font des news contrairement à nous"]

- plus d'introspection "dynamique", mais de la méta-prog template (TMP) qui s'y substitue parfois, quand la TMP n'est pas utilisée pour d'autres choses (à tord comme à raison).

- pas de type Object racine de tout type défini par le développeur, vive les templates!

- ...


Côté ED(I)s, je conseillerai VC++2008, C::B, ou à la limite des vrais éditeurs (vim, emacs).

Côté bibliothèques : la SL tout simplement pour les conteneurs et les algorithmes. boost (dans un premier temps par défaut) pour quantité d'extensions hétérogènes (threads, réseau, autres conteneurs, i18n, calcul matriciel, tableaux 2d, regex, sérialisation, ...). Qt est à la mode pour les IHMs.

Citation:

---

Envoyé par atha2

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

---

Seulement si la sémantique et les ressources encapsulées le dictent.

Citation:

---

Envoyé par ath2

Sachant que ces derniers(getteur/setteur) doivent être déclaré inline cela oblige-t'il à les coder dans le header ?

---

Si tous tes accesseurs et mutateurs sont des trivaux setters/getters qui peuvent être définis inline, et que tu en as une paire pour chaque donnée, c'est que tu as foiré quelque chose dans ton design.
Sinon, pour en revenir à la technique, on peut les mettre inline, mais ce n'est pas nécessaire. Et inline implique définition visible dans toute unité de traduction qui s'en sert (une unité de traduction == un .cpp plus tous les .h et .inl directement et indirectement inclus depuis le .cpp). Tu t'y prends comme tu veux, le tout est que la définition inline soit visible.

Citation:

---

Envoyé par loufoque

[des new] Moi j'en mets nulle part (à part quelques placement new dans des briques bas-niveau)

---

Par curiosité comment tu fais un Pimpl sans new ? Ou tu n'en utilises pas du tout ?
(désolé ça n'a rien à voir avec le sujet initial)

MAT.

Quand je dois allouer de la mémoire, j'utilise des choses bien plus fines que operator new qui est une vraie daube à mon humble avis.
Si jamais je devais l'utiliser, ce ne serait certainement pas à l'extérieur de l'interface du template implémentant le pimpl idiom.

Citation:

---

Envoyé par loufoque

Quand je dois allouer de la mémoire, j'utilise des choses bien plus fines que operator new qui est une vraie daube à mon humble avis.

---

Tu utilises quoi ?

Laisse moi deviner : des allocateurs custom ou des pools?

Il y a un certain nombre de problèmes avec l'interface de operator new/delete, et dans une moindre mesure avec l'interface des allocateurs standard.
- Pas de réel support de l'alignment
- Pas de réelle distinction entre la taille de l'objet et le nombre d'objets alloués
- Pas de réelle distinction entre l'allocation d'un nœud et l'allocation de tableaux (plus ou moins la même chose que le point précédent)
- Pas de réel support de l'agrandissement et la réduction d'un tableau, d'un côté ou de l'autre.

Je n'ai pas de solution idéale, mais j'ai pas mal réfléchi sur le sujet.

Il serait dommage en particulier de ne pas faire usage de certaines propriétés statiques requises par C++ mais qui ne sont pas exploitées :
- Celui qui détruit doit savoir s'il s'agit d'une allocation de nœud ou de tableau (plus ou moins équivalent à utiliser delete[] pour un new[])
- Celui qui détruit doit savoir l'alignement et la taille de l'objet (équivalent au delete, sauf qu'ici le destructeur virtuel n'aide pas)

De plus, à part dans les cas avec du partage de propriété, j'oblige à ce que le thread qui libère soit le même que celui qui alloue (se généralise d'ailleurs à tout type de ressource), autant exploiter ça aussi.

Idéalement j'aimerais aussi supporter directement l'allocation sur la pile et la Small Buffer Optimization directement dans l'allocateur, mais c'est potentiellement problématique sans double stockage.

Petite question de POO, en C++ peut t'on :
- à partie d'un objet de type A accéder à un attribut déclaré privé d'un autre objet de type A ?

Code:

---

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

Class A { public : void test(&A autreInstance) { this->var = 5;//pas de problème autreInstance.var = 5;//possible ou pas ? } private : int var; //variable privé };

---

Je pose cette question car en Java une telle manœuvre est possible, ce qui paraît logique car l'encapsulation ne sert qu'à empêcher l'utilisateur de d'accéder au mécanisme interne de la classe.
EDIT : Je vient de tester et apparemment ça compile mais j'avais vu dans un tutoriel que ce n'était pas censé marcher.

Si si, c'est normal, c'est comme ça que ça fonctionne également en C++.

C'est tout à fait correct et c'est utilisé la plupart du temps lorsque l'on définit des constructeurs de copie.

Par contre, il faudra que tu passes la référence (le "&") de l'autre côté de "A" ;)

Citation:

---

EDIT : Je vient de tester et apparemment ça compile mais j'avais vu dans un tutoriel que ce n'était pas censé marcher.

---

Ton tutoriel a faux (comme tu la vu), car en C++ toute classe est amie d'elle même (on dit aussi que le C++ réalise une encapsulation au niveau de la classe et non de l'objet.)

Je n'ai pas tout lu, mais ce que je peux dire de mon expérience des vendredis (je passe en revue les check-ins de la semaine) à propos des programmeurs Java qui sont "forcés" de faire du C++ (3 permanents, et souvent les stagiaires):
- d'une façon général ils n'ont aucun problème
- ils structurent peut-être un peu trop par des hiérarchies profondes. Par exemple, la décomposition suivante ne leur vient pas naturellement:

Code:

---

1 2 3 4

class infrastructure { ...infrastructure... }; template < class T > class Utile : public infrastructure { ...comportement spécialisé... };

---

- ils utilisent moins les horreurs venues du C, ce qui se ressent très positivement sur la fiabilité
- je vois arriver des emballages suspects masquant des MFC, libs open source GPL et autres trucs interdits chez nous, parce qu'ils manquent d'un tas de commodités que le C++ ne fournit pas.
- et ils foutent des new partout, bordel! ça m'énerve :mouarf:

C'est peut-être spécifique à mon équipe, mais les programmeurs formés en Java sont aussi plus jeunes que la moyenne, c'est sans doute aussi pour ça qu'ils s'adaptent si bien.
Pour le problème du "new partout" (c'en est vraiment un), j'ai du mal à faire adopter les librairies C++ (STL, et surtout certains trucs pédants de Boost, qui ne passe carrément pas).

Donc si j'ai bien compris, on utilise :

• std::string *chaine = new string(); -> agrégation
• std::string chaine; -> composition
• char *chaine = malloc(10 * sizeof char); -> ne jamais utiliser !!

J'ai bien compris ??

On utilise le code 2 et uniquement le 2!

Effectivement c'est le code 2 uniquement. Le code 1 est typiquement le syndrome du "new partout" auquel je faisais allusion dans mon post précédent. Techniquement, il n'est pas fautif, mais il tend la joue (il faut libérer manuellement chaine à un moment donné, car pas de GC automatique en C++), pour aucune bonne raison: le code 2 est plus naturel lors de l'utilisation de l'objet, car on n'a pas besoin de dépointer.
En gros, si j'ai un seul conseil à donner: "new ==> drapeau rouge". 9 fois sur 10 un "new" écrit par un programmeur formé en java sera inutile, voire néfaste, en C++. Il est très dommage que ce mot-clé soit repris à l'identique dans les deux langages, car les deux concepts différent très significativement.

Ce "dommage" est corrigé en C++/CLI, qui fait la différence entre les deux (new vs. gcnew).

Citation:

---

Envoyé par Luc Hermitte

On utilise le code 2 et uniquement le 2!

---

Oui... mais uniquement parceque le std::string est un TYPE....
Si c'était un objet.... :)

Java ne propose pas de "TYPE", et on est obligé de passer par un objet, c'est CA la grosse différence (et la raison des 'new' partout :) ).