Petite question rapide:
 
Y-a-t'il une différence entre:
 

 
?  
 
Tous 2 marchent, et le deuxième est plus "clair" je trouve... mais peut-être qu'il y a un interêt à utiliser le new ?

Bien sur qu'il y en a un : essaie donc, sans le new, d'implementer une classe de liste chainee ou de tableau redimensionnable, tu verras bien la ou ca coince!
 
L'interet du new, pour faire simple, c'est que c'est toi qui decide de la duree de vie de ton objet, alors que si tu le declares en tant que variable locale il meurt a la fin du bloc. Par consequent tout ce qui a ete alloue avec new a besoin d'etre explicitement desalloue via delete.
 

oui, sur le principe c'est exactement la meme chose.  
 
sauf qu'avec le new, il ne faut pas oublier de faire le  "delete monTriangle" quand tu n'en as plus besoin.
 
En tant que "debutant", tu n'as peut etre pas bien compris la nuance de l'allocation dynamique...
Les objet "vivent" tant que tu n'as pas fais de delete, il sont donc disponible partout dans l'application du moment que tu as stocké leur pointeur quelque part; contrairement aux objets alloués statiquement (sans new) qui meurent à la fin du bloc où ils sont déclarés ( comme le dit Ace17 )
 
Un autre inconveignant a utiliser les pointeurs quand on en pas besoin, c'est l'utilisation du ->  et de *  pour acceder à l'objet lui meme.C'est quand meme moins lisible qu'un simple . (point)

Hm merci    
 
Dans l'exo que j'ai à rendre, j'utilise effectivement une liste châinée. Dans le main(), j'ai donc besoin d'une seule liste principale qui va contenir mes objets (triangles et autres formes, ainsi que des listes de formes). J'ai donc déclaré ma liste Principale sans New, la "fin du bloc" étant la fin du main ... non ?
 
Enfin je comprends la différence entre les 2 grace à vos explications, mais je ne suis pas sûr d'avoir compris quelle méthode utiliser dans mon cas ^^
 
Pour vous montrer de quoi je parle, voici le shéma que j'ai fait pour ma structure de données:
http://orgasm.free.fr/hfr/shemac++.jpg
 
et voici le sujet initial:
http://orgasm.free.fr/hfr/sujetc++.jpg
 
Pour toutes les formes que je vais créer, il faudra donc les créer en new, et ma liste je peux la laisser en "statique" dans le main ? (pareil pour les groupes ?)
 
 

Si tout est géré dans le main, je ne vois pas ce qui t'empêche de créer les objets sur la pile (sans le new qui utilise le tas) et de faire ton association dans la liste chaînée en passant un pointeur pour chacun.

Le new permet un passage de paramètres par pointeur, le deuxième example permet le passage par valeur.
 
Si tu utilise tout le temps new, tu devra gérer l espace mémoire en supprimant toi même les variables avec delete. Ta variable est un pointeur vers l emplacement mémoire qui contient les valeures. Il est possible de récupérer la valeure avec l opérateur *: par ex. (*triangle);
 
Avec le passage par valeur une copie de l objet est necessaire. L objet est automatiquement détruit quand le bloc est refermé (à l aide de }). Essayer d accéder à une variable en dehors de son bloc produit une erreure de compilation. Il est possible de connaitre l emplacement mémoire avec l opérateur &: par ex. (&triangle).
 
Concrètement, avec new et delete tu as besoin uniquement de définir un constructeur et un destructeur. Tu doit ensuite gérer la vie de tes variables, sinon tu risque une erreure à l exécution (comme accéder à un pointeur avant un new ou après un delete). Le sys. dexploitation fermera de force ton programme dans ce cas.
 
Avec le passage par valeur tu doit en plus définir le constructeur de copie:
ClassName(const ClassName& );
et l opérateur de copie:
ClassName& operator=(const ClassName& );
(note: sauf dans le cas particulier ou tu n a pas besoin de constructeur/destructeur, les opérateurs qui te sont alors fournis par défaut conviennent).
Enfin, tu doit tout de même te décider sur la manière de gérer les propriétés de ton objet: si ton objet necessite beaucoup de mémoire (une image par example), il n est pas très judicieux de laisser l opérateur de copie doubler de grande quantités de mémoire. Tu peut utiliser des passages par paramètres de cette façon:
void Fonction(ClassName& );
qui passe en réalité un pointeur sur ton objet (celui ci ne doit par conséquent pas être temporaire), en évitant la copie.
 
Il y a beaucoup de façon de gérer la mémoire, et je n ai donné l example que des façons naturellement supportées par C++. Tu peut toi même élaborer des gestions de mémoire plus complexes, mais gérées lors de l exécution.
 
Pour une liste chaînée, tu as le choix entre une liste autodelete (qui se charge de créer/supprimer les objets lorsque la liste est vidée ou les éléments insérés/supprimés), et une liste sans autodelete qui stocke uniquement des pointeurs et laisse le programmeur en charge de créer/supprimer les objets en dehors de la liste.
 
L autodelete est une solution complète de liste, aussi appelé liste de valeur. Sans autodelete la liste est plus facile à écrire, elle est aussi appelée liste de pointeurs.
 
Pour une liste tu peut aussi définir les opérateurs:
const Objet& operator [] (unsigned int); // par ex. Triangle t=liste[i]
ObjetElement& operator [] (unsigned int); // par ex. liste[i]=Triangle(...);
Et les opérateurs d ajout:
Liste& operator << (const Objet& ); // ajout objet
Liste& operator << (const List& ); // ajout liste
 
Bon courage!

OK, en fait ta liste principale est une Forme  (classe de base qui contiendra des formes).
Oui, Cette liste peut etre declarée dans le main en statique.
 
Cette liste  ( de type Forme) aura des methodes pour ajouter des formes ( Triangle, Rectangle ) et contiendra un pointeur vers une liste chainée d'objet de type Forme.
C'est donc un pointeur car la liste chainée est dynamique ( 0 ou n objets dans la liste ), le nombre de poste n'est pas définit à l'avance.
Les objets de la liste sont donc bien créés par des news.
 
Pense bien a faire des methodes de suppression des objet en memoire  
 
C'est un peu chaud comme projet, rien que le parser de ligne de command !  d'ailleurs il y avait déjà une question a ce sujet sur ce forum !  toi peut etre !?

Merci beacoup pour toutes ces précisions ...
 
Pour ma liste, je n'ai pas fait une liste de pointeurs, mais d'objets !
 
Mon .h:
 

 
Et j'ajoute donc directement les objets par recopie. Mais maintenant, que je fasse un triangle avec un "new" ou sans, je peux l'ajouter dans les 2 cas avec les méhodes de ma liste !
 
Sinon pour parcourir la liste, j'ai un itérateur:
 

 
et un iterateur d'écriture, hérité de l'itérateur 'normal":
 

 
Grace à tout ça, je peux manipuler ma liste comme je veux, y ajouter des Formes (qui ne sont rien d'autres que des "objets" particuliers !)
 
Comme décrit ds le shéma ( http://orgasm.free.fr/hfr/shemac++.jpg ) en haut à droite, "tout est objet" ... de façon à pouvoir ajouter ET des formes ET des groupes de formes dans ma liste principale.
 
Maintenant, vu que tout va se jouer dans le main() avec une seule liste principale (qui contiendra mes formes, ou mes groupes de formes (qui sont des nouvelles listes de formes ^^)), je peux donc tout créer sans new ... ? L'analyseur de ligne de commande ne va que disséquer la commande entrée, et renvoyer au main un constructeur d'une forme, comme par ex mon triangle  
 

 
J'ai bon ?
 
Le sujet est effectivement plutot dur, surtout pour nous qui n'avons jamais fait ni de C (très peu) ni de C++ ... mais que du Java ^^ Et en Java, les constructeurs par recopie et tout ça, ça n'existe pas. Tout comme les pointeurs, d'ailleurs. Du coup, désolé d'insister un petit peu la dessus ... m'enfin vous m'avez déja bien aidé. L'autre question posée sur le forum a du etre postée par mon binome de Projet ^^
 
 

Ça me semble nickel.
 
Tu devrait quand même utiliser:
void ajoutFin(Objet& );
void ajoutTete(Objet& );
Node::Node(Objet& );
etc...
Ça permet au compilateur de lui indiquer de passer le pointeur seulement au lieu d une copie de l objet.
 
Perso, j aurais appelé la classe Liste un Arbre, simple nuance de vocabulaire.

iostream.h n'est pas standard (et il est inutile dans le .h, peut etre dans le .cpp ...), il faut utiliser iostream

 
Mais si je fais ça, je serais obligé de créer tous mes objets à insérer en New, non ? Si c'est ça, j'ai compris l'intérêt Sinon, non    
 
Pour iostream, par contre, je n'ai pas compris. Je sais que je peux laisser de coté le "h", mais je pensais que ça revenait au même ?

 
il y a deux facon de passer une variable à une fonction/méthode en C++, passage par valeur (par défaut) ou passage par référence (avec le & apres le type de l'argument dans le prototype de la fonction). Ces deux méthodes sont complement indépendantes du type d'allocation de la variable (c'est simple, ca n'a rien à voir)
 
quand tu passes un objet par valeur, tu récupère une copie dans la fonction, si tu le modifies ca ne le modifieras pas dans le code appelant (c'est en fait une variable local à la fonction), sémantiquement ca convient dans tout les cas ou on n'a pas besoin de conserver les modifications faites sur l'objet apres l'appel de la fonction
 
quand tu passe un objet par référence, tu récuperes dans la fonction une référence (!= de pointeur) sur l'objet dans le code apelant, cette référence est comme un alias de l'objet, c'est juste un nom qui désigne le meme objet. de ce fait toute les modifications faites sur l'objet dans la fonctions porteront apres l'appel de la fonction car c'est le meme objet que tu manipulais. sémantiquement ca sert principalement à pouvoir modifier un parametre de la fonction, mais ca peut aussi etre utilisé (pour des raisons d'efficacité) pour éviter la copie inutile d'un objet (qui peut etre tres lourde alors qu'un référence peut etre assimilée à un pointeur mais ca on s'en fou) sans toutefois avoir besoin de le modifier, dans ce cas on ajoute le mot cle 'const' avant (ou apres) le type qui indique le parametre ne pourra pas etre modifier dans la fonction bien qu'il s'agisse d'un passage par référence
 
du coup c'est déja plus logique d'écrire
 
void ajoutFin(const Objet& );
void ajoutTete(const Objet& );

Non, que dalle, examples:
 
int length(Image* i) { return i->mylength; }
- passe un pointeur (adresse mémoire de l objet = copier un nombre entier d environ 4 octets). retourne une copie du champs longueure.
 
int length(Image i) { return i.mylength; }
- recopie une image de 15MégaOctets en mémoire, plus les autres champs, puis appelle la fonction qui détruit la copie de 15MégaOctets devenue inutile avant de retourner une copie du champs longueure.
 
int length(Objet& o) { return o.mylength; }
- passe un pointeur (environ 4 octets). retourne une copie du champs longueure.
 
Il est fortement conseillé de virer le .h pour raisons de portabilité obscures.
 

 
non, iostream.h et iostream sont bien deux headers différent, la différence c'est que iostream.h date du c++ pré standard et en gros quand le standard est arrivé il a été décidé que tout les headers publiques de la bibliothèque standard ne devaient etre sans extension (et tout les noms dans le namespace std). cependant les compilateurs  fournissent encore les versions avec .h (et nom dans le namespace globale) pour la rétro compatibilité.
 
si ton prof te dis d'utiliser iostream.h c'est qu'il ne connais pas le c++

C ça, passage par référence, je me rappelais plus le nom... en réalité ça utilise un pointeur (caché). Dans certains cas très rares le compilateur peut gnogner contre l utilisation de référence d un objet temporaire. Dans ce cas forcer une copie de l objet à l aide de la déclaration d une variable supplémentaire. Cela indique que l opération souhaitée n est possible qu a la condition de copier l objet préalablement.

 
oui, pour ne pas embrouiller autant dire recopie d'une variable de type pointeur sur image, parce que ca reste du passage par valeur, et surtout c'est 'c-style' on preferera un passage par référence constante dans ce cas en c++
 

 
ca passe une référence, on s'en fou qu'au niveau du code généré c'est comme si on passait un pointeur, les référence c'est justement pour ne plus avoir à se faire chier avec ca alors pas besoin de remettre ca sur le tapis

 
ça je pense avoir compris, mais ma question portait plutot sur le type d'argument que je donne a ma méthode: Actuellement, je lui donne un Objet en valeur. Si je le passe en référence, je serais obligé de modifier la façon dont je crée les objets que je vais lui passer ?  
 
Exemple concret: L'implémenation de la méthode "ajouter en tête" (telle qu'elle est actuellement)
 

 
Et pour l'utiliser, je fais comme cela:
 

 
Je pourrai quand-même l'utiliser comme ça, mon ajout, si je lui change la signature "objet" en "objet&" ? (je testerai demain, pas possible là ^^)
 
   

 
ben ouai, qu'est ce qu'on en a foutre de comment à été aloué l'objet ?

Merci beacoup de ton aide  

hehe. ok, pointeur, référence, c est la même chose. je ne souhaitait pas commencer une <<flame war>>.
Mais puisque le sujet est lancé: les références ne servent qu aux programmeurs trop fainéants pour taper ->.
hehe. je blague.
 
Sérieusement, le passage par référence laisse le compilateur trouver lui même un pointeur sur l objet, sans avoir à lui préciser explicitement ce pointeur à l aide de new. Mais il est toujours utile de connaître le fonctionnement de la compilation.  
Tu peux remplacer tous les Objet en Objet&. Si le compilateur ne trouve pas le pointeur lui même il te le dira.

 
Sauf honteuse malversation, une reference "pointe" tjs vers quelque en vie. Tout leur interet est la
 
 

 
hen ?
 
 

 
ouais mais nan, ca se fait pas a la legere, ca se reflechi, ca se const-ise, ca se jauge, ca se tate
 

 
(re-hein)

heu, ok... ça devient technique.
Oui une référence pointe toujours sur quelquechose en vie. C est un des intérêts face aux pointeurs.
 
<<ca se fait pas a la legere>>
 
Entièrement d accord. En fait ça se prévoit. Dans le cas du code de Liste ça ne semble pas trop présenter de complications, étant donné la longueure du programme.
 
<<Si le compilateur ne trouve pas le pointeur lui même il te le dira. >>
 
Ça peut paraître obscur, certes. Disons qu un objet est stocké à un emplacement mémoire. Un pointeur ou une référence est un nombre qui est la <<coordonnée en mémoire>> de l objet. Ça prends beaucoup moins de place que l objet en entier.
 
Le seul cas pour lequel je suis sûr qu un objet n a pas d emplacement mémoire est lorsque l objet tient entièrement dans un registre. Dans ce cas, pas de référence possible vers l objet. D où warning du compilateur, qui est obligé de forcer à stocker l objet en mémoire centrale. Rem: dans ce cas une référence n est pas nécessaire car l objet est trop petit.
 
Ça m est arrivé plusieurs fois pourtant d avoir une erreure Fatale du compilateur dans une ligne telle que: a=b=(a+b)*c<<d , avec abcd des objets. Je n ai pas d example concret, mais utilisant GCC, j ai eu des erreures style: Cannot take address of temporary object. Si vous avez des explications à ça je veux bien (où est passé l objet?). Dans ce cas je déclare des variables pour stocker les résultats temporaires et ça compile. Peut être que j avais oublié un constructeur?
 

Petite recherche sur internet et je trouve:
In C++, temporary objects are treated as const, so one way to solve the problem is to change
void test(MyClass & rTest)
to
void test(const MyClass &rTest)
 
Voilà, j ai l explication. En C++ les objets temporaires sont traité comme constants.

 
Heuh je veux pas etre mechant, mais d'un point de vue programmeur, que l'objet tienne ou non dans un registre, on s'en fout. Tu peux avoir une reference vers un char si ca te chante, le compilo n'a rien a dire la dessus
 

 
heuh bah, heuh, t'es sur d'avoir compris l'interet d'une reference ?
 
 

Autre explication:
<<Temporaries May Vanish Before You Expect>>
Les objets temporaire peuvent disparaîtres avant qu on s y attende.
Ça arrive en fait lorsque l on retourne une référence sur un membre d une classe. Dans le cas d un objet temporaire il peut être supprimé lorsque l on utilise la référence.
Certains compilateur n ont pas ce problème, mais c est pourtant le comportement requis pour un compilateur standardisé.
 

Ouah! Je viens de relire.
Non une référence ne pointe pas toujours sur quelquechose en vie. C Dingue.

Quelqu'un a t-il tenté de modéliser le problème de Paradox ?
 
As tu prévu le cas où un groupe tente de s'inclure lui même ?
Peut on définir des groupes croisés ?
 
a) (A - B) - C : 1 groupe G1 = (A,B)
b) (A - [B) - C] : 2 groupes croisés G1 = (A,B) et G2 = (B,C)
c) [(A - B) - C] : 2 groupes G1 = (A,B) contenu dans le groupe G2 = (G1,C)

voila ce que j'entendais par "honteuse malversation"

D'où l'intérêt des auto_ptr ?

 
Hello !
 
Alors, pas de groupes croisés, si une figure est dans un groupe, elle n'est "plus libre" pour un autre groupe. En revanche, on doit pouvoir faire des groupes de groupes ... c'est pourquoi il est important qu'un groupe soit autant un "objet" qu'une simple figure !

 
whats teh rapport ? D'une maniere generale les conversions pointeur => reference, ca sent un peu du bout (et qu'on vienne pas me chier dans les bottes avec le return *this )

D'où l'intérêt du garbage collector ?