Discussion :

[kedare]

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 !

[aziz jim]

tu trouveras des réponses à toutes ces questions ici
http://c.developpez.com/faq/cpp/

[JolyLoic]

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

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

[tut]

faut pas se faire une montagne des pointeurs... ce n'est pas si compliqué. C'est juste une adresse en mémoire...

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

[rigobert]

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.

[loufoque]

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.

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

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

[loufoque]

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.

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

[loufoque]

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.

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

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.

[zais_ethael]

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.

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

[roulious]

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.

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é ?

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.

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

Comme la facilité de troller sur ses caracteristiques objet ?

[Luc Hermitte]

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

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 )

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.

[loufoque]

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.

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.

[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")

[roulious]

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]

[Médinoc]

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!