C et C++ (diff�rences).

Version imprimable

10/05/2015, 13h35
Luke spywoker

C et C++ (diff�rences).

Salut les C++,

je m'incruste un peu dans la discussion et je ne sais si je suis la bienvenue.

Je pratique le python depuis 5 ans et le C depuis 2 ans.

Le but de ma question est d'aller a la p�che au infos concernant le C++.

Citation:

std::vector, Array, Vector...

Est-ce les tableaux dont vous parlez ont des m�thodes internes comme append(), insert(), pop()... ?

Citation:

Array est un tableau C/C++ "d�guis�" statique ( pas de new/malloc) plus s�curitaire.
Vector est un tableau C/C++ "d�guis�" dynamique ( new/malloc ) plus s�curitaire.

Est-ce que la gestion de la m�moire est prot�g�e en C++ (automatique) ?

Le but et de p�cher des infos avant de m'investir dans l'apprentissage du C++.

Merci pour vos pr�cieuses r�ponses �clair�es.

PS: d�sol� pour l'incrustation dans la discussion de joffrey575, mais c'�tait trop tentant car je me pose ces questions, entre autres, depuis trop longtemps.
10/05/2015, 16h43
white_tentacle

Les tableaux dynamiques ont des m�thodes push_back, pop_back. Les tableaux statiques n�en ont pas : leur taille est fixe (je crois que ce concept n�existe pas en python).

En c++, la gestion de la m�moire (et des ressources en g�n�ral) est... automatique si tu le souhaites, manuelle si tu le souhaites. Le mot d�ordre est RAII/RFID (Resource Acquisition Is Initialization, Resource Finalization Is Destructor), qui sont deux acronymes barbares pour dire en gros qu�une ressource doit �tre acquise dans un constructeur est lib�r�e dans un destructeur, ce qui permet de conna�tre pr�cis�ment sa dur�e de vie.

Venant du C, il te faudra oublier un certain nombre de choses (par exemple, les pointeurs, l�allocation avec malloc, etc) pour te mettre au C++, afin de ne pas tomber dans les travers du � C with classes � qu�on voit un peu trop souvent, et qui est une tr�s mauvaise mani�re de faire du C++.
10/05/2015, 19h38
Bousk

les tuples pourraient �tre vus comme l'�quivalent Python des array C++ amha
11/05/2015, 00h39
koala01

Salut,

Citation:

Envoy� par Luke spywoker

Salut les C++,

je m'incruste un peu dans la discussion et je ne sais si je suis la bienvenue.

Je pratique le python depuis 5 ans et le C depuis 2 ans.

Le but de ma question est d'aller a la p�che au infos concernant le C++.

Est-ce les tableaux dont vous parlez ont des m�thodes internes comme append(), insert(), pop()... ?

Toutes les collections de la STL proposent un certain nombre de fonctions membres, mais ne proposent que les fonctions qui sont adapt�es au type de collection envisag�.

Ainsi, std::vector (tableau de taille dynamique) et std::list (liste chain�e) proposent (entre autre) [/codeinline]push_back[/codeinline], pop_back, insert alors que std::set (arbre binaire de recherche) et std::map (tableau associatif "cl�/valeur" utilisant un arbre binaire de recherche sur la cl�) proposent que insert, erase et find car... il n'y a pas de sens � vouloir obliger un nouvel �l�ment � se trouver "en derni�re position" dans un arbre binaire. De la m�me mani�re, std::stack (pile LIFO) et std::queue (file FIFO) ne proposeront que push, et pop car on place forc�ment le nouvel �l�ment "apr�s les autres".

Pour pouvoir utiliser correctement ces collections, il est souvent int�ressant d'aller voir du cot� de cppreference.com ou de cplusplus.com afin d'avoir la documentation compl�te, mais, de mani�re g�n�rale, les noms de fonctions restent "logiques" par rapport � l'utilisation qui est faite de ces collections ;)

Citation:

Est-ce que la gestion de la m�moire est prot�g�e en C++ (automatique) ?

Pas forc�ment :
C++11 (l'avant derni�re norme en date) est venue avec la notion de "pointeurs intelligents" (std::unique_ptr et le couple std::shared_ptr /std::weak_ptr) qui s'assurent que la m�moire allou�e dynamiquement est correctement lib�r�e avant de perdre le pointeur.

Tu te douteras que l'on pousse un maximum les gens � les utiliser car cela permet de gagner �norm�ment en robustesse au niveau des programmes d�velopp�s ;)

Cependant, bien que nous essayerons de t'en dissuader, tu peux aussi prendre (l'�norme) le risque de vouloir g�rer toi-m�me la m�moire � la main. Tu peux le faire... mais ce n'est tr�s certainement pas la meilleure d�cision que tu prendra ;)

Bien sur, toutes les collections de la STL g�rent �galement parfaitement la m�moire qui leur est allou�e, mais uniquement celle pour laquelle elles ont elles-m�me fait la demande de la m�moire. Si tu places un pointeur "nu" repr�sentant une adresse m�moire allou�e par new dans une collection, la destruction de la collection n'aura pas pour effet d'invoquer delete sur ce pointeur.

Par contre, si tu places un pointeur intelligent dans une collection de la STL, la collection se chargera de la m�moire qu'elle a elle-m�me demand�e et le pointeur intelligent se chargera de la m�moire que tu as demand�e, et tu auras quelque chose de particuli�rement robuste ;)

Citation:

Le but et de p�cher des infos avant de m'investir dans l'apprentissage du C++.

Il n'y a aucun probl�me, mais garde toujours en t�te que, bien que C++ "descend" du C (un peu comme le francais descend du latin de Jules Cesar), il s'agit de deux langages totalement diff�rents, tant dans leur philosophie que dans la mani�re d'aborder certains probl�mes.

Beaucoup de "bonnes pratiques" dont on peut te rabattre les oreilles en C sont consid�r�es comme mauvaises, dangereuses et nocives en C++. Au final, le seul gros avantage que tu auras � avoir pratiqu� le C, c'est que tu connais la syntaxe de base (et encore, tu n'en connais qu'une partie) et que tu es sans doute habitu� au syst�me d'inclusion et � tout ce qui a trait au pr�processeur ;)
11/05/2015, 10h05
stendhal666

Citation:

Est-ce que la gestion de la m�moire est prot�g�e en C++ (automatique) ?

C'est un peu LA question centrale du C++ ! Le cr�ateur du langage consid�re que la gestion automatique par un garbage collector (la solution retenue par la plupart des langages r�cents, de Java � Python en passant par Haskell ou Ruby), quoiqu'elle puisse �tre une solution adapt�e � certains cas de figure, ne doit pas �tre la m�thode par d�faut et encore moins la seule m�thode. En cons�quence, le C++ propose diff�rentes mani�res de g�rer la m�moire:

Sur le "tas" (allocation dynamique de la m�moire):
1. comme le C avec les fonctions C: ce n'est pas recommand� mais toutes les fonctions standards du C sont disponibles en C++ (free, malloc, realloc, calloc, etc.).
2. comme le C avec les op�rateurs C++: les op�rateurs new et delete remplacent free et malloc (avec des tas de nuances tr�s subtiles, qu'il est parfois difficile de s'approprier). Il faut en revanche �tre coh�rent: on ne peut pas lib�rer avec un op�rateur C++ la m�moire allou�e avec une fonction C et vice-versa. NB: il y a plusieurs new et plusieurs delete.
3. comme le C avec les op�rateurs C++ au sein des classes: une classe d�finit un constructeur qui alloue la m�moire et un destructeur qui la lib�re. Si ce travail est fait correctement, la classe peut �tre utilis�e sur la pile comme un type natif sans se pr�occuper plus de la gestion de la m�moire. La biblioth�que standard d�finit un bon nombre de classes (vector, string, map, etc.) o� ce travail est d�j� fait.
4. la m�thode 3 peut �tre g�n�ralis�e dans 2 directions:
4.a. RAII: ce n'est plus seulement la m�moire mais toute ressource partag�e qui est allou�e/lib�r�e par le couple constructeur/destructeur: les fichiers, connexions aux bases de donn�es, sockets, etc.
4.b. les pointeurs intelligents (qui g�rent allocation et destruction de la m�moire sur laquelle ils pointent) permettent d'appliquer l'idiome RAII � n'importe quelle allocation dynamique, sans d�finition d'une classe sp�cifique.
5. la norme C++ pr�voit que le langage offre le support n�cessaire � la cr�ation d'un garbage-collector. Je ne connais pas bien le sujet mais il est fort possible que tu puisses en trouver un sous la forme de biblioth�que.

Sur la "pile"
Dans ces cas-l�, pas de gestion explicite de la m�moire!

En conclusion, je pense que tu fais bien de te lancer dans le C++ qui est tr�s diff�rent et de C et de Python. Un bon point de d�part est le livre de B. Stroustrup: programming principles using C++ (http://www.stroustrup.com/programming.html)
11/05/2015, 11h19
Iradrille

Citation:

Envoy� par stendhal666

Sur la "pile"
Dans ces cas-l�, pas de gestion explicite de la m�moire!

Avec quand m�me une nuance, on sait quand l'objet va �tre supprim�. Avec un garbage collector on � rarement cette garantie: l'objet va �tre supprim� � un moment ou � un autre, mais on ne sait pas quand.
13/05/2015, 08h28
Luke spywoker
Merci beaucoup pour toutes vos r�actions didactiques,

Et j'ai une bonne nouvelle:

Je vient de d�buter le C++, 200 pages d'un livre depuis le poste.

En fa�tes pour l'instant j'apprends donc je n'ai pas grand chose a dire, mais vous en avez d�j� dit beaucoup.

Avec tous les conteneurs, je n'ai pas vue de m�thode pour lib�r� les conteneurs afin de les d�truire alors doit ont laisser la masse de m�moire allouer s'amasser, a moins de faire une boucle:
Code:

1 2 3 4 while ( vec.size() != 0 ) { vec.pop_back() }
afin que la m�moire soit d�sallouer par des m�canismes internes.

Bon il y a une part de r�ponse dans le poste de stendhal666 et la cr�ation personnel d'un Garbage collector...

Je posterai dans le forum adapt� et vous laisse la main pour r�pondre a la question initiale, pendant ce temps je vais me retirer dans mon bureau afin d'apprendre les rouages du C++.

Merci pour vos r�ponses.

Avec les conteneurs standards, tu ne t�occupes en g�n�ral pas de � lib�rer la m�moire �. Si tu veux vider ton conteneur, tu peux utiliser la m�thode � clear � : cela d�truira chacun des �l�ments du conteneur, mais en revanche la m�moire allou�e par le conteneur lui-m�me ne sera pas lib�r�e. Si tu veux vraiment lib�rer cette m�moire elle-m�me, tu peux utiliser la m�thode � shrink_to_fit �.

Mais tu ne le feras que tr�s rarement, en effet :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 int f(bool toto) { if(toto) { std::vector<int> v; for(int i = 0; i < 1000; ++i) v.push_back(i); return v.capacity(); // v sera automatiquement détruit ici, la mémoire allouée libérée. } else return 0; }
C�est une diff�rence assez majeure et fondamentale avec C, qui simplifie �norm�ment la vie. En C++, la question fondamentale est � quelle est la dur�e de vie de mes resources ? �.

En cours de vie de la collection, tu peux utiliser clear().

Et surtout, le destructeur d'une collection d�salloue sa m�moire interne.
Chaque �l�ment est alors d�truit par son destructeur propre.
Cela ne pose probl�me qu'avec un pointeur, car le "destructeur" d'un pointeur (comme tout type primitif) est simplement de l'oublier. Il n'y a pas d'appel � delete.

C'est � l'utilisateur de lib�rer son vecteur, s'il a allou� les pointeurs. (par sym�trie: qui alloue lib�re)
Ce que tu peux �crire ainsi: for(auto p : collection) delete p;.

pop_back() retire l'�l�ment de la collection, mais ca ne lib�re pas forc�ment la m�moire. Ca d�pend de la collection: une liste chain�e la lib�rera, pas un vecteur. Quant au deque, je ne sais plus.

En C++, on se repose �norm�ment sur le destructeur pour poser des garanties.
En effet, cette fonction poss�de une propri�t� extraordinaire: elle est appel�e une et une seule fois pour chaque variable (dont le constructeur n'a pas lev� d'exception).
Cette propri�t� est au coeur d'un principe que tu vas apprendre � connaitre et � aimer: le RAII.

L'id�e, c'est que le constructeur d'une classe acquiert une ressource ch�re, et son destructeur la lib�re.
Il y a plusieurs exemples plus ou moins anciens

std::string contient un pointeur vers un tableau de caract�res.
std::vector<T> contient un pointeur vers un tableau de T
std::unique_ptr<T> contient/est un pointeur vers un T, et s'assure d'en �tre l'unique propri�taire. Ce faisant, il sait pouvoir faire son delete sans soucis.
std::fstream contient un fichier qu'il ouvre et ferme judicieusement.

Comme une variable est lib�r�e d�s qu'on sort de sa port�e de d�claration (son scope), il suffit de d�clarer les variables au "dernier moment".
Code:

1 2 3 4 5 6 7 8 9 10 11 #include <fstream> int main () { int i; { std::ifstream fichier("chemin.txt"); fichier >> i; }//c'est ici que la variable fichier est détruite, et donc que fichier.~ifstream() est appelée, fermant le fichier. i*=2; //on peut faire plein de chose, encore, ce n'est pas un soucis, le fichier est déjà fermé :D return i; }
La cons�quence, c'est qu'il peut devenir utile de faire une petite capsule pour les contextes obtenus dans les biblioth�ques C.
Prenons l'exemple de la SDL, une biblioth�que graphique.
Voici l'exemple de base, pris sur leur site
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 int main(int argc, char** argv) { capsule_SDL sdl( if (SDL_Init(SDL_INIT_VIDEO|SDL_INIT_TIMER) != 0) { fprintf(stderr, "\nUnable to initialize SDL: %s\n", SDL_GetError() ); return 1; } atexit(SDL_Quit); /* ... */ return 0; }
Remarque le magnifique atexit(), qu'on pourrait oublier.

Avec un minimum de propret�, une capsule pourrait s'�crire ainsi:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 /* une exception */ struct SDL_exception : std::runtime_error { SDL_exception() : std::runtime_error(SDL_GetError()) {} }; /* la capsule proprement dite */ class SDL { SDL(Uint32 mode) { if (SDL_Init(mode) != 0) throw SDL_exception(); } ~SDL() {SDL_Quit();} };
L'avantage imm�diat, c'est que l'exemple devient maintenant:
Code:

1 2 3 4 5 6 7 8 9 10 11 int main(int argc, char** argv) { try { SDL sdl(SDL_INIT_VIDEO|SDL_INIT_TIMER); /* PAS de atexit(SQL_Quit); */ /* ... */ return 0; } catch (SDL_exception const& e) { std::cerr << "Unable to initialize SDL: "<<e.what() << std::endl; return 1; } }
J'ai la m�me gestion d'erreur, mais par contre, je n'ai plus du tout � m'inqui�ter de la fermeture.

En effet, quelle que soit la fa�on dont on quitte le programme, je sais qu'on aura un appel � SQL_Quit.

Dans un vrai code, il faudrait ajouter un namespace (ou plusieurs) autour de cette capsule, pour �viter tout risque d'interf�rence avec la biblioth�que.
J'ai en g�n�ral tendance � utiliser deux namespaces, raii en premier, puis le nom de la biblioth�que. ainsi, la classe serait raii::sdl::sdl.

PS: J'aurai pu �tre encore plus vicieux, et �crire ma classe en gardant le atexit, mais en interne:
Code:

1 2 3 4 5 6 struct SDL { SDL(Uint32 mode) { if (SDL_Init(mode) != 0) throw SDL_exception(); atexit(SDL_Quit); } };

Ah non, rien de tel!

1. mettons que tu d�clares un vecteur de string:
Code:

1 2 3 4 5 6 7 { // début de la portée std::vector<std::string> vs; /* là tu le remplis */ } // lorsqu'on sort de la portée où vs est déclaré, tous les éléments du vector sont détruits (leur destructeur est appelé) ainsi que vs lui-même.
2. Ce comportement (hautement d�sirable) n'est en revanche pas suivi si tu d�clares un vecteur de pointeurs sur des strings:
Code:

1 2 3 4 5 6 { // début de la portée std::vector<std::string*> vs; /* là tu le remplis */ } // lorsqu'on sort de la portée où vs est déclaré, les pointeurs contenus dans vs disparaissent (ce sont des copies des originaux) mais pas les strings sur lesquels ils pointent
La conclusion c'est qu'il faut toujours pr�f�rer l'option 1, qui applique l'idiome RAII (les ressources sont acquises par le vecteur qui se chargera de leur lib�ration), lorsqu'elle est suffisante. Le seul cas o� elle ne l'est pas est lorsqu'un comportement polymorphique est recherch� (pointeur sur une hi�rarchie de classes, lorsque la fonction � appeler d�pend de l'objet sur lequel le pointeur pointe), mais c'est peut-�tre pour plus tard dans ton apprentissage.

20/05/2015, 13h39
oodini

Puisque tu passes au C++ depuis Python, je en peux que te sugg�rer que d'employer � outrance le const ; la notion n'est gu�re pr�sente en Python.
J'ai fait quant � moi le chemin inverse ces derniers mois (C++ -> Python), et j'ai souffert (pour moi, Python est un peu un langage de hippies, compar� � C++).
20/05/2015, 14h11
prgasp77

1 pi�ce(s) jointe(s)

Citation:

Envoy� par oodini

Python est un peu un langage de hippies

Pi�ce jointe 178266

D�sol� :aie:.

Resalut les gars ++,

le python est parfait pour d�buter la programmation quand on y connait rien, apr�s le C ouvre beaucoup de portes et ce qui tourne autour du C/C++ ca enseigne pas mal de choses avec un brin d'assembleur c'est nickel !!!

Effectivement le "C-Like C++" est absolument a �viter d'apr�s ce que j'ai lu et la notion de scope qu'une variable n'existe que dans sa port� est pas mal car automatiquement d�truit.

Mais j'ai une petite question que je pense de mes 200 pages de lectures sur le C++ non r�solvable.

Je vais vous l'expliquer en pseudo C++ en omm�tant des choses:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 class Point { public : ... /** Operator overloading Point + Point == Line **/ Line operator + (Point p) ; } class Line { public : /** Contructor **/ Line(Point p1, Point P2) ; ... }
En faite j'aimerai utiliser un objet de type Point dans mon contructeur d'objet de type Line
et aussi avoir une m�thode de de la classe Point qui renvoie un objet de type Line (ici par surcharge d'op�rateur).

Ce que je pense pas possible �tant donn�e que l'une des deux classes doit �tre d�clar� avant l'autre ce qui fait qu'on ne peut pas faire appel a l'autre avant sa d�claration ???

Point + Point == Line n'a pas vraiment de sens :

Code:

1
2
3
4
5
Point a;
Point b;
 
auto result = a + b; // result de type Line
auto result = a += b; // result de type Point

Mais disons que c'est pas grave.

Tu as 2 fa�ons de r�soudre ce genre de probl�mes :
Avec une d�claration anticip�e (solution g�n�rale).

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class Point; // déclaration anticipée : on donne seulement le nom de la classe
 
class Line {
public :
 
	// ctor, pas besoin de la déclaration complète de la classe pour
	// utiliser des refs : on peut référencer le type.
	// il faudra par contre fournir la déclaration de Point lors
	// de l'implémentation
	Line(Point const& p1, Point const& P2);
};
 
class Point {
public:
	// Operator overloading Point + Point == Line
	Line operator+(Point const& p) const; 
};

En utilisant le fait que operator+ n'a pas besoin d'�tre une fonction membre:

Code:

1
2
3
4
5
6
7
8
9
10
11
class Point {
	double x, y;
};
 
class Line {
public :
	Line(Point const& p1, Point const& P2);
};
 
// operator+ est donc une fonction libre, Line et Point sont déclarés à ce moment
Line operator+(Point const& lhs, Point const& rhs);

22/05/2015, 09h17
stendhal666
Si, si, ne t'inqui�te pas... Mais il est vrai que c'est une source de probl�mes quand deux classes se font r�f�rence mutuellement, probl�mes qui disparaissent assez vite � condition de suivre certaines bonnes pratiques.

En l'occurrence tu fais � mon avis une faute conceptuelle parce que tu couples trop �troitement tes deux classes. Si une ligne est d�finie par des points, la classe des points est "ant�rieure" logiquement � celle des lignes et ne devrait pas y faire r�f�rence. De plus une classe Point a bien d'autres usages que de cr�er des lignes, et il serait dommage d'avoir � compiler la classe ligne � chaque fois que tu utiliseras Point, y compris pour un autre usage. Dans la m�me ligne, je crois que la surcharge d'op�rateur est mal employ�e: l'addition de deux points peut retourner une ligne, mais aussi bien un vecteur, un rectangle ou je ne sais quoi.

L'usage serait plut�t de cr�er tes classes dans deux fichiers diff�rents (ou plut�t quatre, deux par classe, un pour la d�claration et l'autre pour la d�finition):
Code:

1 2 // point.h class Point { ... };
Code:

1 2 3 4 5 6 7 // line.h #include "point.h" class Line { ... Line(const Point& a, const Point& b); ... };
N�anmoins, si tu veux persister dans la surcharge d'op�rateur, il n'est pas n�cessaire de le d�finir dans la class Point. Tu peux le faire dans le fichier "line.h", en dehors de la class Line:

Code:

Line operator+(const Point& a, const Point& b);

D�finir les op�rateurs de surcharge en dehors du corps de la classe est une bonne pratique. Cela permet de conserver l'encapsulation des donn�es: les op�rateurs font r�f�rence � un accesseur offert par la classe et n'ont pas � �tre modifi�s un par un si tu en changes l'impl�mentation.

En tout cas je te rejoins sur un point, 200p de C++ ce n'est pas suffisant pour conna�tre toutes les subtilit�s de l'�dition des liens, qui est une des difficult�s particuli�res du couple C/C++, surtout quand on vient de langages o� les modules sont impl�ment�s (le C++ pourrait �voluer dans ce sens, d'ailleurs).
22/05/2015, 09h23
stendhal666

Citation:

Envoy� par Iradrille

Tu as 2 fa�ons de r�soudre ce genre de probl�mes :
Avec une d�claration anticip�e (solution g�n�rale).[code]class Point; // d�claration anticip�e : on donne seulement le nom de la classe

class Line {
public :

// ctor, pas besoin de la d�claration compl�te de la classe pour
// utiliser des refs : on peut r�f�rencer le type.
// il faudra par contre fournir la d�claration de Point lors
// de l'impl�mentation
Line(Point const& p1, Point const& P2);
};

+1 pour la rapidit� mais:
une d�claration anticip�e ne permet pas d'utiliser compl�tement la classe. On peut utiliser simplement un pointeur sur la classe, parce qu'il faut que la taille de l'objet soit connue lors de la compilation, ce qui n'est pas le cas lors d'une simple d�claration.
22/05/2015, 10h40
ternel

Un pointeur ou une r�f�rence...
Nous avons dans la faq une question sur ce sujet
22/05/2015, 10h52
stendhal666
Indeed. Je voulais souligner qu'une d�claration anticip�e ne ferait pas l'affaire pour:
Code:

1 2 3 4 5 6 class Line; class Point { ... Line operator+ (const Point& a, const Point& b); };
O� un objet line est construit...

Mais effectivement ce n'est pas le bout de code qu'Iradrille visait
22/05/2015, 11h04
ternel

Tu es sur de ca? il me semble que pour un type de retour, ca pouvait aller
22/05/2015, 11h44
stendhal666

Pour �tre tout � fait exact, on peut d�clarer une fonction qui retourne un type qui n'a pas �t� d�fini, mais on ne peut pas d�finir une fonction qui retourne un type qui n'a pas �t� d�fini.
Encore une de ces joyeuset�s du syst�me de compilation/�dition de liens du C/C++...
22/05/2015, 12h14
Luc Hermitte

Un modo pourrait d�placer cette digression vers un nouveau topic ? Car il y a un vilain d�tournement ici.
Merci.