Le C/C++ Me Conviendrait-il ?

Version imprimable

23/07/2006, 21h13
kedare

Le C/C++ Me Conviendrait-il ?

Salut a tous !

je programme actuellement en python ,
mais je cherche un second langage de programmation (orienté objet), qui permette de faire du "natif" (sans interpreteur) , pour pouvoir distribuer plus facilement mon application (10mo une fenetre en python pour crée un exe ...) , je compte surtout faire des petites applications au debut
j'hésite entre l'ocaml (dur dur le fonctionnel) , et le C/C++ (dur dur les pointeurs)

j'ai essayer de faire un peut de C , je comprend presque tout ... sauf ... les pointeurs , la c'est l'horreur , je n'en vois pas l'utilité et je n'y comprend pas grand chose :(
j'ai entendu dire que l'on pouvais faire du C++ sans utiliser les pointeurs , c'est vrais ?
c'est mieu de commencer par le C avant le C++ ou pas ? parceque j'ai du mal sans Programmation Orienté Objet (j'en ai toujour fait :) )
quelle est le meilleur cours d'apres vous pour l'apprendre ? :)

merci !
23/07/2006, 21h26
aziz jim

tu trouveras des réponses à toutes ces questions ici
http://c.developpez.com/faq/cpp/
23/07/2006, 22h09
JolyLoic

Citation:

Envoyé par kedare

j'ai entendu dire que l'on pouvais faire du C++ sans utiliser les pointeurs , c'est vrais ?

C'est souvent un peu exagéré. Je dirais Plutôt qu'il permet d'isoler l'utilisation de pointuers nu en quelques endroits bien définis, de façon à ce que la majorité du code ne les manipule pas directement. Mais comprendre ce qu'est un pointeur reste à mon avis indispensable avant de pouvoir écrire un vrai programme (pour des programmes d'apprentissage, on peut s'en passer un certain temps).
24/07/2006, 01h29
Luc Hermitte

Et arrivé à la POO, les pointeurs sont vite indispensables.
Par contre, c'est clair que dans l'apprentissage ils ne sont pas une notion clé de la première leçon de C++, contrairement au C.

PS: je te déconseille vivement tout ouvrage, tuto, ... qui cherche à t'enseigner le C/C++. C Très bien. C++, très bien aussi. Mais C/C++ -> cheminée.
24/07/2006, 13h57
tut

faut pas se faire une montagne des pointeurs... ce n'est pas si compliqué. C'est juste une adresse en mémoire...
24/07/2006, 14h26
loacast

Le problème avec les cours traitant des pointeurs se sont le manque d'exemple permettant d'en voir l'intérêt. Mais bon, au fure et à mesure des développements, on se rend compte vite que l'on en a besoin et ça fini effectivement par être compris un jour ou l'autre.
24/07/2006, 16h31
rigobert

Citation:

Envoyé par loacast

Le problème avec les cours traitant des pointeurs se sont le manque d'exemple permettant d'en voir l'intérêt. Mais bon, au fure et à mesure des développements, on se rend compte vite que l'on en a besoin et ça fini effectivement par être compris un jour ou l'autre.

A condition d'avoir le temps...
A défaut, il risque de se retrouver vite coincé avec des bugs liés plus ou moins directement aux pointeurs, et si le sujet n'est pas maitrisé ce sera très rapidement l'impasse.
24/07/2006, 22h14
loufoque

Citation:

j'ai entendu dire que l'on pouvais faire du C++ sans utiliser les pointeurs , c'est vrais ?

Oui.
Tu peux en avoir besoin pour du polymorphisme, mais dans ce cas il existe des solutions pour les gérer de manière appropriée.
25/07/2006, 00h35
millie

C'est vrai que dans pas mal de cours que j'ai pu lire, c'était difficile de voir l'interêt de pointeur.

On pouvait se demander pourquoi, lors de l'appel d'une fonction, ne pas passer directement en argument l'élément (donc, pas par son pointeur). En général, dans les cours que j'ai pu lire, il n'indique pas grand chose sur le fait que les arguments sont mis sur une la pile, et donc qu'il peut y avoir facilement des débordements de pile si la structure passée en paramètre est trop importante.
26/07/2006, 17h05
Spartan03

Les pointeurs vont très vite te devenir utiles lorsque tu aura besoin d'allouer de la mémoire dynamiquement. Le problème c'est qu'en général, les allocations dynamiques viennent bien après le cours sur les pointeurs dans la plupart des cours c++.
En c++ il existe aussi les références, qui permettent dans certains cas de remplacer les pointeurs.

Mais un pointeurs, ça n'a rien de bien compliqué, une fois que tu auras compris comment ça marche, tu va trouver ça très simple (et très utile).

On ne peut pas vraiment dire qu'on peut ne pas se servir des pointeurs en c++. Cepandant, ils sont en général beaucoup moins utilisés qu'en C.

Vu que j'ai le temps, je vais essayer de t'expliquer le principe d'un pointeur:

Ton PC à de la mémoire vive (RAM). Quelque soit ton language de programmation, lorsque tu crée une variable, elle est stockée à un endroit de la RAM. Par exemple, à l'adresse 100 (à la case 100 en gros).

Un pointeur, ce n'est rien qu'une variable, qui occuppe une case en mémoire (par exemple l'adresse n°500).

Cepandant, ton pointeur va contenir une valeur particulière (dit toi que c'est un nombre) qui correspond à l'adresse d'une autre variable.

Par exemple, si notre pointeur (à l'adresse 500) pointe sur notre variable, il aura pour valeur 100.

Pour modifier la variable on pourra écrire "*pointeur = nouvelle_valeur".
Ce qui veut littéralement dire : "Ce que pointe "pointeur" = nouvelle_valeur".
Ca revient à écrire "variable = nouvelle_valeur" mais tu verra que dans certains cas tu devra travailler avec des pointeurs (ou des références en c++).

Sinon, le c++ est un très bon langage mais bien que ça va te changer de Python. Enfin une fois que tu maitrisera le concept de bibliothèques, si tu sais utiliser Google, il se révélera bien plus puissant que la plupart des autres langages.
26/07/2006, 20h26
loufoque

Citation:

Les pointeurs vont très vite te devenir utiles lorsque tu aura besoin d'allouer de la mémoire dynamiquement.

Ce qui est essentiellement utile pour faire des conteneurs de taille variable.
Et pour ça tu utilises des classes spéciales, pas des pointeurs.

Les ressources pour apprendre le C++ sur internet ne sont pas très bonnes.
Il est plutôt conseiller d'acquérir des livres.
27/07/2006, 00h20
zais_ethael

Bon, je vais aussi essayer de décrire un peu ce que sont les pointeurs.
Tout d'abord, les pointeurs c'est inutile. Ben ouais, avec du python tu n'en a pas et pourtant tu as la un langage permettant beaucoup plus de choses niveau syntaxe.

Mais alors pourquoi on en utilise en C++? Ben... tu dois surement savoir qu'il y a une assez grosse différence de performances entre le C++ et le python, c'est ca l'explication. En fait, le python utilise des pointeurs, il n'utilise même que ca, sauf que tu ne le vois pas. Quand tu passes un objet en argument d'une fonction et que cette fonction va modifier ton objet, après la fin de cette fonction l'objet reste modifié. Ceci s'explique par le fait que ce n'est pas une copie de l'objet qui a été passé à la fonction, c'est une copie du pointeur de l'objet (qui permet donc de retrouver l'objet en lui même, ce dernier n'ayant jamais été copié). En plus le python (tout comme le java, le c# et tous les autres langages purs objets) utilise un système pour détruire automatiquement l'objet quand il n'est plus utilisé.

Or tous ces systèmes, bien que géniaux pour programmer, font perdre considérablement en optimisation. Le C++ est plus vieux et bien plus proche de la machine. En C++ quand tu déclares une variable elle n'a pas de pointeur, tu y accèdes directement. Quand tu la passes à une fonction c'est une copie de la variable que tu passes. Donc tu peux modifier ta variable autant que tu veux ca ne sert à rien (même si le compilateur te laisse faire, j'ai toujours trouvé ca un peu idiot d'ailleurs), une fois la fonction terminée la copie de la variable est détruite point à la ligne.

Quand tu utilises un pointeur, tu récupères un "truc" qui permet de retrouver ta variable et pas une fulgaire copie. Si tu passes ce pointeur à une fonction c'est une copie du pointeur qui est effectuée, mais cette copie te permet toujours de retrouver la variable elle même.

Ca c'était pour le C, en C++ c'est bien différent (les réfèrences pour commencer, puis toutes les classes qui te filent un coup de main pour les opérations de base). Mais on les utilise encore pour régler d'autres problème (surtout pour faire de l'orienté objet, car non, en C++ l'orienté objet ne tombe pas du ciel, il faut le simuler).

Voila, j'èspère t'avoir aidé à comprendre. Accroche toi, il te reste encore un bout de chemin à parcourir pour arriver à faire du c++ :mouarf:
27/07/2006, 02h03
loufoque

Citation:

En plus le python (tout comme le java, le c# et tous les autres langages purs objets) utilise un système pour détruire automatiquement l'objet quand il n'est plus utilisé.

L'utilisation d'un ramasse-miettes n'est aucunement liée à la caractérisation objet d'un langage.
D'ailleurs le fait d'utiliser un ramasse-miettes pour tous les objets est une mauvaise idée : cela n'aide qu'a gérer la mémoire, pas les autres ressources avec lesquelles le déterminisme du RAII (idiome de base de la gestion des ressources - et donc de la mémoire - en C++) est bien plus robuste.

Citation:

(surtout pour faire de l'orienté objet, car non, en C++ l'orienté objet ne tombe pas du ciel, il faut le simuler).

Il ne faudrait pas exagérer non plus.
Bien qu'il soit nécessaire de réferencer d'autres objets (avec des références ou des pointeurs) pour faire du polymorphisme, parler de simulation de l'objet est extrémement exagéré.
En C, ça l'est néanmoins car l'héritage relève du bidouillage et il y n'y a pas d'encapsulation.

Citation:

Le C++ est plus vieux et bien plus proche de la machine.

Les deux affirmations ici ne sont pas nécessairement vraies.
Java date de 1996, C++ de 1998, même s'il existait avant sous une forme expérimentale depuis 1983. Enfin, c'est une simple histoire de versions.
Et C++ dispose de fonctionnalités d'abstraction plus elevées que Java, bien que C++ ait aussi des fonctionnalités bas niveau.
27/07/2006, 21h52
zais_ethael

Citation:

Envoyé par loufoque

L'utilisation d'un ramasse-miettes n'est aucunement liée à la caractérisation objet d'un langage.
D'ailleurs le fait d'utiliser un ramasse-miettes pour tous les objets est une mauvaise idée : cela n'aide qu'a gérer la mémoire, pas les autres ressources avec lesquelles le déterminisme du RAII (idiome de base de la gestion des ressources - et donc de la mémoire - en C++) est bien plus robuste.

Le ramasse miette (ou l'utilisation de smart pointer - ca revient au même) est indirectement mais inéluctablement lié au concept de l'orienté objet. En C++, tous les variables sont placées sur la pile, ce qui signifie que leur taille doit être connue à la compilation. Or l'orienté objet spécifie clairement qu'un objet peut à n'importe quel moment être de n'importe quelle taille - c'est parfaitement incompatible. Dans des langages purs objets on ne se préocupe d'ailleurs jamais de l'occupation mémoire, mais il est indéniable qu'on y perd en optimisation.

Citation:

Envoyé par loufoque

Il ne faudrait pas exagérer non plus.
Bien qu'il soit nécessaire de réferencer d'autres objets (avec des références ou des pointeurs) pour faire du polymorphisme, parler de simulation de l'objet est extrémement exagéré.
En C, ça l'est néanmoins car l'héritage relève du bidouillage et il y n'y a pas d'encapsulation.

Prenons un exemple en langage Java. Imaginons des classes A et B qui ne sont pas de notre conception (pas de possibilité de les modifier). Une méthode de A prend comme argument un objet B, puis cette méthode appelle quelque méthodes de B. En Java, on peut si on le veut faire une classe dérivant de B, redéfinir ses methodes et passer un objet de cette nouvelle classe à la methode de A. Tout ca fonctionnera à tous les coups.
Par contre en C++... le nombre de conditions à remplir pour permettre ceci est faramineux. Il faut que toutes les méthodes qu'on veut redéfinir soient virtuelles, que la classe A n'aie pas la mauvaise idée de copier l'objet de B,... Autant dire qu'à moins que ce ne soit spécifié dans la doc c'est impossible.
Autre exemple: on démarre un projet, on se crée une petite classe qu'à priori on a pas l'intention de faire hériter, on en fait des copies par valeur ect... On passe deux mois à faire son applic puis on finit par se rendre compte qu'on doit faire une classe dérivée de notre petite classe, sauf qu'on en a déja fait une utilisation intensive partout dans le code. Il faut donc vérifier quasi tout son code pour être sur que ca colle bien à la nouvelle façon de s'en servir.
Ou alors on concoit direct toutes ses classes pour faire de l'héritage mais ca personne ne le fait jamais :mrgreen:
Non, le C++ c'est du pseudo objet. Ca reste possible d'en faire mais c'est beaucoup trop intrusif. Ca n'en reste pas moins un langage interessant, pour d'autres raisons.
27/07/2006, 23h07
roulious

Citation:

Envoyé par zais_ethael

Le ramasse miette (ou l'utilisation de smart pointer - ca revient au même)

Non. Les smart pointer ajoutent de l'intelligence aux pointeurs, c'est tout. Pour les smart pointers qui font du comptage de référence, on peut s'en servir comme ramasse miettes, mais ça n'est pas leur seul usage.

Citation:

Envoyé par zais_ethael

Or l'orienté objet spécifie clairement qu'un objet peut à n'importe quel moment être de n'importe quelle taille

Dans quelle définition ? Quel le rapport entre la taille d'une variable en mémoire et les caracteristiques objet d'un langage donné ?

Citation:

Envoyé par zais_ethael

Autre exemple: on démarre un projet, on se crée une petite classe qu'à priori on a pas l'intention de faire hériter, on en fait des copies par valeur ect... On passe deux mois à faire son applic puis on finit par se rendre compte qu'on doit faire une classe dérivée de notre petite classe, sauf qu'on en a déja fait une utilisation intensive partout dans le code.

C'est souvent la preuve d'une erreur de conception dès le début. En démarrant un projet, il vaut mieux perdre du temps à bien le concevoir, qu'à se faire une petite classe dont dépend le projet et qu'on devra jeter par la suite.

Citation:

Envoyé par zais_ethael

Ca n'en reste pas moins un langage interessant, pour d'autres raisons.

Comme la facilité de troller sur ses caracteristiques objet ? :D
27/07/2006, 23h09
Luc Hermitte

Citation:

Envoyé par zais_ethael

Le ramasse miette (
a- ou l'utilisation de smart pointer - ca revient au même)
b- est indirectement mais inéluctablement lié au concept de l'orienté objet.

c- Or l'orienté objet spécifie clairement qu'un objet peut à n'importe quel moment être de n'importe quelle taille - c'est parfaitement incompatible.

d- Prenons un exemple en langage Java. Imaginons des classes A et B qui ne sont pas de notre conception (pas de possibilité de les modifier). Une méthode de A prend comme argument un objet B, puis cette méthode appelle quelque méthodes de B. En Java, on peut si on le veut faire une classe dérivant de B, redéfinir ses methodes et passer un objet de cette nouvelle classe à la methode de A. Tout ca fonctionnera à tous les coups.

e- Par contre en C++... le nombre de conditions à remplir pour permettre ceci est faramineux. Il faut que toutes les méthodes qu'on veut redéfinir soient virtuelles, que la classe A n'aie pas la mauvaise idée de copier l'objet de B,... Autant dire qu'à moins que ce ne soit spécifié dans la doc c'est impossible.

f- Autre exemple: on démarre un projet, on se crée une petite classe qu'à priori on a pas l'intention de faire hériter, on en fait des copies par valeur ect... On passe deux mois à faire son applic puis on finit par se rendre compte qu'on doit faire une classe dérivée de notre petite classe, sauf qu'on en a déja fait une utilisation intensive partout dans le code. Il faut donc vérifier quasi tout son code pour être sur que ca colle bien à la nouvelle façon de s'en servir.
Ou alors on concoit direct toutes ses classes pour faire de l'héritage mais ca personne ne le fait jamais :mrgreen:

g- Non, le C++ c'est du pseudo objet. Ca reste possible d'en faire mais c'est beaucoup trop intrusif. Ca n'en reste pas moins un langage interessant, pour d'autres raisons.

a- Pas exactement. Au fond, ils servent tous deux à faciliter la gestion de la mémoire. En creusant, il y a des points de détails qui changent la façon de les utiliser. Cf toute la problématique des références cyccliques.

b- C'est vrai que ce n'est pas comme si LISP, Prolog, ML, Perl, ... n'étaient pas des langages OO :?
http://en.wikipedia.org/wiki/Garbage...ter_science%29

c- Euh ... Je sais bien que personne n'est d'accord sur la définition de OO. Mais là, tu sors carrément des sentiers batus. C'est quoi tes références ? (Frell! Même à l'époque où je fréquentais fufe je ne posais pas cette question :oops:)

d- Ce n'est pas parce qu'on peut bourriner comme des sagouins et supplanter tout et n'importe quoi que cela a du sens dans le monde OO. Cf le fait que dériver une liste triée depuis une liste, ou dériver un carré depuis un rectangle brise le LSP.
De plus, c'est sans parler qu'une fonction virtuelle trop grosse est difficile à supplanter si elle n'a pas découpé proprement ses traitements. Mon expérience me fait plus dire qu'il faut refactorer en profondeur pour introduire des template methods (p.Ex.) que simplement supplanter la première fonction qui ne nous plait pas.

e- Le C++ contrairement à java supporte deux sémantiques pratiquement opposées : la sémantique de valeur (ou les objets sont copiables et comparables), et la sémantique d'entité (ou les objets sont au mieux clonables, et non comparables).
La syntaxe permet d'écrire n'importe quoi, mais aussi de blinder le code pour p.ex., empêcher la copie lorsque l'on part sur de la sémantique d'entité. Force la sémantique d'entité est très simple. Empécher la dérivation publique est plus difficile (il y a un hack pour y parvenir), là il faut partir dans l'éducation des masses. Et en attendant bien documenter son code.

Et la virtualité n'a jamais été une condition nécessaire au LSP que tu évoques.

f- Ben oui, c'est un cas de refactoring. D'un autre côté cela veut dire que l'on ne s'est pas posé la question de la sémantique à attribuer à la classe. Et puis rien ne nous empêche de passer des références dès le début.
Perso beaucoup de mes classes sont conçues pour ne jamais être héritées.

g- :? Multi-paradgime, c'est bien comme terme aussi. :P
28/07/2006, 01h16
loufoque

Citation:

le nombre de conditions à remplir pour permettre ceci est faramineux

Elle est unique : savoir au moment de la conception quels éléments doivent agir de manière polymorphe.

En Java, c'est le cas de tous les objets. Ce qui est d'ailleurs un gaspillage inutile.

Citation:

Le ramasse miette (ou l'utilisation de smart pointer - ca revient au même)

Il y a plusieurs types de pointeurs intelligents qui répondent tous à une problématique différente et qui ne sont pas forcément assimilable aux ramasse miettes.
Quoi qu'il en soit, il reste toujours la différence que la durée de vie de l'objet reste déterminée, même si dans le cas de l'appartenance partagée avec shared_ptr cette détermination peut être difficile à percevoir.
28/07/2006, 10h52
Médinoc

Corrigez-moi si je me trompe, mais pour moi, le ramasse-miettes est un complément du comptage de références (pointeurs intelligents) : Selon ce que j'ai compris, le ramasse-miettes sert à libérer ce que le comptage de référence n'a pas pu libérer automatiquement: Les groupes inacessibles d'objets qui se référencent entre eux ("références cycliques")
28/07/2006, 16h21
roulious

Citation:

Envoyé par Médinoc

Corrigez-moi si je me trompe, mais pour moi, le ramasse-miettes est un complément du comptage de références (pointeurs intelligents) : Selon ce que j'ai compris, le ramasse-miettes sert à libérer ce que le comptage de référence n'a pas pu libérer automatiquement: Les groupes inacessibles d'objets qui se référencent entre eux ("références cycliques")

On peut se servir uniquement d'un ramasse miette, à condition qu'il soit au courant de tous les objets dont il doit s'occuper. Voir par exemple celui de Boehm (http://www.hpl.hp.com/personal/Hans_Boehm/gc/). Attention, la page est un peu fouillis à mon goût, les exemples ne sautent pas aux yeux.

[edit]Hop, on vire la parenthèse de l'url pour la mettre dehors[/edit]
28/07/2006, 16h47
Médinoc

Citation:

Envoyé par Ton lien

Sorry, the page you requested was not found on this server. You may search this server, using the search box at the top of this page, or go the HP Labs homepage for more information.

Si le GC marche même sur les pages Web, j'achète tout de suite! :aie:
28/07/2006, 22h18
zais_ethael

Citation:

Envoyé par roulious

Non. Les smart pointer ajoutent de l'intelligence aux pointeurs, c'est tout. Pour les smart pointers qui font du comptage de référence, on peut s'en servir comme ramasse miettes, mais ça n'est pas leur seul usage.

"Smart pointeur à comptage de réfèrence" c'est long à taper, et tout le monde connait pas forcément le shared_ptr.

Citation:

Envoyé par roulious

Dans quelle définition ? Quel le rapport entre la taille d'une variable en mémoire et les caracteristiques objet d'un langage donné ?

Il est vrai que dans le concept objet, un objet n'est défini que par les méthodes qu'il offre. Néanmoins, techniquement, un objet doit bien contenir des données - leurs tailles variant d'une classe dérivée à l'autre. D'où le fait que ce concept est incompatible avec la création des variables sur la pile comme en C/C++.

Citation:

Envoyé par roulious

C'est souvent la preuve d'une erreur de conception dès le début. En démarrant un projet, il vaut mieux perdre du temps à bien le concevoir, qu'à se faire une petite classe dont dépend le projet et qu'on devra jeter par la suite.

Je me marre :D Alors toi tu fais un programme et tu n'as jamais besoin de revenir sur ta décision? Un bout de code tapé c'est un bout de code jamais réécris? Ca m'a l'air encore pire que de mal concevoir une applic. En java, tant qu'on essaye de bien réutiliser le code c'est assez facile de modifier l'architecture - en C++ pas.

Citation:

Envoyé par roulious

Comme la facilité de troller sur ses caracteristiques objet ? :D

Troll Power :twisted:
28/07/2006, 22h41
zais_ethael

Citation:

Envoyé par Luc Hermitte

Empécher la dérivation publique est plus difficile (il y a un hack pour y parvenir), là il faut partir dans l'éducation des masses.

Ben justement, tu pourrais m'expliquer :lol:
Non, franchement ca m'interresse.
28/07/2006, 23h27
roulious

Citation:

Envoyé par zais_ethael

"Smart pointeur à comptage de réfèrence" c'est long à taper, et tout le monde connait pas forcément le shared_ptr.

En parlant de comptage de référence, je disais que les smart pointers ne servaient pas qu'à faire du ramasse miette, voir ce thread (en anglais) : http://groups.google.fr/group/comp.l...e9ab72ae0a19b8

Citation:

Envoyé par zais_ethael

Je me marre :D Alors toi tu fais un programme et tu n'as jamais besoin de revenir sur ta décision? Un bout de code tapé c'est un bout de code jamais réécris?

J'ai l'impression que tu mélanges un peu l'interface des classes/fonctions/... avec ce qu'il y a dedans. L'interface (ce qui est destiné au client de tes classes) doit rester le plus fixe possible pour casser le moins de choses possibles lorsque tu t'apperçois que tu as fait hériter une classe Carre d'une classe Rectangle. Après ça, tu peux bidouiller en interne tant que tu veux, les utilisateurs de ton code n'en voient rien.
28/07/2006, 23h51
zais_ethael

Citation:

Envoyé par roulious

J'ai l'impression que tu mélanges un peu l'interface des classes/fonctions/... avec ce qu'il y a dedans. L'interface (ce qui est destiné au client de tes classes) doit rester le plus fixe possible pour casser le moins de choses possibles lorsque tu t'apperçois que tu as fait hériter une classe Carre d'une classe Rectangle. Après ça, tu peux bidouiller en interne tant que tu veux, les utilisateurs de ton code n'en voient rien.

Non, je parlais bien de l'interface. L'ennui, pour reprendre les mots de luc, c'est que si on crée une classe selon la sémantique par valeur on ne peut pas la transferer aisément vers celle par entité. Le problème est bien entendu que tout programme est appelé à changer - quand bien même il était très bien concu à la base (durée de vie moyenne d'un programme = 10 ans - impossible de prévoir tout pendant la première phase de conception).
29/07/2006, 00h43
Luc Hermitte

Citation:

Envoyé par Médinoc

Corrigez-moi si je me trompe, mais pour moi, le ramasse-miettes est un complément du comptage de références (pointeurs intelligents) : Selon ce que j'ai compris, le ramasse-miettes sert à libérer ce que le comptage de référence n'a pas pu libérer automatiquement: Les groupes inacessibles d'objets qui se référencent entre eux ("références cycliques")

Je ne dirais pas complémentaire. C'est différent. Je me vois difficilement utiliser les deux sur des mêmes données. Avec les pointeurs intelligents les durées de vie restent maitrisées/implicitement connues, comme il l'a été dit plus loin.
Les GC sont plus simples à manipuler dans les cas de références cycliques -- et encore, j'ai lu (rumeur sur internet, tout ça) que le premier GC de Java n'en était pas capable. Avec les pointeurs intelligents (ceux à comptage de référence) il y a quand même moyen de contourner les problèmes de références cycliques, mais cela demande à ce que l'on distribue les responsabilités dans les cycles.

(Il me semble, qu'il y a une variété de pointeurs intelligents qui savent malgré tout s'en sortir).

Sur le lien que j'avais donné, il y a un mini "encart" sur les pointeurs intelligents.

Citation:

Il est vrai que dans le concept objet, un objet n'est défini que par les méthodes qu'il offre. Néanmoins, techniquement, un objet doit bien contenir des données - leurs tailles variant d'une classe dérivée à l'autre. D'où le fait que ce concept est incompatible avec la création des variables sur la pile comme en C/C++.

Un objet ne contient pas nécessairement des données. Tu sembles systématiquement associer des objets à des entités. Une fois de plus, cela n'a pas à être nécessaire -> matrices, chaines de caractères, ...

Citation:

Citation:

Empécher la dérivation publique est plus difficile (il y a un hack pour y parvenir), là il faut partir dans l'éducation des masses.

Ben justement, tu pourrais m'expliquer
Non, franchement ca m'interresse.

Je suppose que tu fais référence au hack qui interdit la dérivation.
Hop : http://www.developpez.net/forums/showthread.php?t=42040 (c'était compliqué à retrouver -- je suis passé par "virtual" et "protected" :?).

Citation:

Non, je parlais bien de l'interface. L'ennui, pour reprendre les mots de luc, c'est que si on crée une classe selon la sémantique par valeur on ne peut pas la transferer aisément vers celle par entité. Le problème est bien entendu que tout programme est appelé à changer - quand bien même il était très bien concu à la base (durée de vie moyenne d'un programme = 10 ans - impossible de prévoir tout pendant la première phase de conception).

Les projets peuvent effectivement évoluer au fil des Demandes de Modification reçues. Surtout si ils durent et que beaucoup de personnes différentes sont passées dessus. Mais ce qui est clair, c'est qu'un changement de sémantique peut s'avérer couteux. Mais bon. Perso je préfère ça à ne pas avoir le choix entre ces deux sémantiques pour mes classes.
29/07/2006, 17h03
zais_ethael

Citation:

Envoyé par Luc Hermitte

Avec les pointeurs intelligents les durées de vie restent maitrisées/implicitement connues, comme il l'a été dit plus loin.

Je ne suis pas d'accord. Certes avec un shared_ptr, par exemple, on sait que l'objet sera détruit quand il ne sera plus réfèrencé. Mais sait-on seulement "quand" il ne sera plus réfèrencé? Prenons le cas d'un objet encapsulant un handler de bas niveau: une socket faisant serveur. Il est très interessant de pouvoir gérer correctement le cycle de vie de cet objet (pour savoir quand le serveur occupe le port). Avec un shared_ptr on ne peut être sur qu'il n'existe plus de réfèrences. On a donc que deux solutions: pas de shared_ptr ou mettre un booléen dans l'objet pour savoir si le handler est toujours actif(ce qu'on ferait en java). Ou alors on essaye de surveiller tout le projet pour être sur de ne pas faire de bétise (pas bon ca). Bref ca montre bien que le problème est le même avec ou sans GC -> on ne controle pas vraiment la durée de vie de l'objet.

Citation:

Envoyé par Luc Hermitte

Un objet ne contient pas nécessairement des données. Tu sembles systématiquement associer des objets à des entités. Une fois de plus, cela n'a pas à être nécessaire -> matrices, chaines de caractères, ...

Si tu veux dire que certain objets ne contiennent pas de données, soit, mais il y en a forcément qui en contiennent aussi, l'un des interets de l'orienté objet étant de ne pas avoir à s'en préoccuper.

Citation:

Envoyé par Luc Hermitte

Mais ce qui est clair, c'est qu'un changement de sémantique peut s'avérer couteux. Mais bon. Perso je préfère ça à ne pas avoir le choix entre ces deux sémantiques pour mes classes.

A part pour des questions d'optimisation, je ne vois pas l'interet. Remarque c'est important aussi, mais pas dans tous les projets (montage vidéo = bien, applic de facturation = pas besoin).
30/07/2006, 01h10
JolyLoic
Le choix de sémantique n'a aucun rapport avec l'optimisation.

Pour une classe gérant des comptes banquaires, une sémantique de valeur serait désastreuse : Un compte banquaire pourrait être copié, on pourrait modifier une copie et pas l'autre, un client aurait donc plusieurs soldes différents...

Pour une classe gérant des grandeurs physiques, une sémantique par entité serait désastreuse. Quand je fais :
Code:

1 2 3 a = 1; b = a; a = 2;
Je n'ai absolument pas envie que b==2.