Discussion :

[Invit�]

printf et scanf moins compliqu�s ?

non l� j'appr�cie cin et cout ... je parlais de fprintf et fscanf , lecture/�criture ds un fichier


d'ailleurs a propos des pointeurs : j'ai pris l'habitude des pointeurs que je passe en param�tres des fonctions:

double* fonction( int *a, char[] name)

si j'ai bien compris en C++ les r�f�rences permettent de simplifier l'utilisation des pointeurs, pas besoin de se demander si c'est un pointeur ou pas:

&double fonction( int &a, char &name) ???

mais je me suis toujours pas d�cid� a remplacer mes * par des & ...

[Luc Hermitte]

Oui mais non. Pas l�!

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

std::vector<double> f(std::vector<int> const &, std::string const &)

Les r�f�rences, ne s'utilisent pas pour acc�der au premier �l�ment des tableaux.

En param�tre, on va garder les pointeurs pour les gros objets optionnels.

Pour ce qui est des fichiers. Soit je pr�f�re passer par des biblioth�ques sp�cialis�es soit, par des parseurs (qui eux utilisent souvent le couple du C) qui me permettent de mieux contr�ler les ereurs de format possibles.

[Invit�]

ok

je vais continuer gentiment avec mes pointeurs pour l'instant

merci

[loufoque]

Luc Hermitte, pourquoi n�cessairement remplacer les tableaux par des vecteurs ?

[Luc Hermitte]

Euh ... Oui, j'aurais du pr�ciser. Cet exemple c'�tait pour montrer le seul type d'utilisation de r�f�rences que je voyais dans le cadre de passage de tableaux.
Les vecteurs ont divers avantages, mais pas exactement au niveau des passages de param�tres (autre que l'on en �conomise un qui avait �t� oubli� ici).

En revanche, je pense qu'il manquait clairement des const dans le premier code, un tout du moins.

[Caine]

Bonjour,

Les vectors sont utiles quand on veut une don�e extensible facilement et s�re, avec les m�mes performances d'acc�s et simpliciter d'ecriture qu'un tableau.

Cependant, m�me si la taille est statique, il est int�ressant de passer par la classe vector, pour les op�rations de recherche...

Mias, on ne d�vie pas un peu du sujet l�

[rolkA]

Bonjour,

Les vectors sont utiles quand on veut une don�e extensible facilement et s�re, avec les m�mes performances d'acc�s et simpliciter d'ecriture qu'un tableau.

Cependant, m�me si la taille est statique, il est int�ressant de passer par la classe vector, pour les op�rations de recherche...

Mias, on ne d�vie pas un peu du sujet l�

A ce sujet, boost::array permet d'avoir les avantages d'un vector pour un tableau de taille fixe, tout en �tant plus rapide puisque le redimensionnement n'est pas g�r�

[Khrrr]

Il n'y a absolument aucun algorithme que l'on ne peut r�soudre que en programmation orient�e objet.

Une machine de turing peut r�soudre n'importe quel algorithme.

ps: une machine de turing est s�quentielle.

[nounouk]

Bonjour,
qlq'un connaitrait il un exemple d'algorithme qui ne pourrait etre resolu qu'en programmation OO (ou alors tres difficilement par un autre type de programmation)?

Normalement le concept objet et d'orienter la programmation autour des donn�es ,ce qui fait que les donn�s sont reutlisables pour des traitements differents .Tu pourraiias aussi ecrire du code c a l'interieur du c++:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
 
extern "c"{
declarations en c
}

[M�dinoc]

si j'ai bien compris en C++ les r�f�rences permettent de simplifier l'utilisation des pointeurs, pas besoin de se demander si c'est un pointeur ou pas:

&double fonction( int &a, char &name) ???

mais je me suis toujours pas d�cid� a remplacer mes * par des & ...

Au contraire, les r�f�rences nuisent � la lisibilit� du code: tu lis ceci:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
cout << a.b;
fonction(a);
cout << a.b; // ?? a.b vient de changer? C'est pourtant pas un pointeur!!

Et si tu lis ceci:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
printf("%08X", a.b); // PS: comment on fait de l'hexa sur 8 chiffres avec cout ?
fonction(&a);        //Ah, un pointeur. S'il n'est pas const, il pourrait bien modifier...
printf("%08X", a.b); //Ah, ben oui il modifie...

Pour moi, les r�f�rences, c'est � n'utiliser que l� o� les pointeurs ne marchent pas : Les surcharges d'op�rateurs, par exemple (et encore, attention aux plaisantins qui s'amusent � modifier une valeur qu'on ne s'attend pas � ce que l'op modifie...

Mais les r�f�rences mises � part, le C++ est plein d'avantages. La facilit� de programmation orient�e objet est bien utile.

[Caine]

Personnellement je trouve que les r�f�rences rendent le code plus facile � lire.

Mais elles sont l� surtout pour emp�cher de passer des pointeurs nuls. Finis la programmation d�fensive � outrance sur (pointeur != NULL).

[Luc Hermitte]

Au contraire, les r�f�rences nuisent � la lisibilit� du code: tu lis ceci:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
cout << a.b;
fonction(a);
cout << a.b; // ?? a.b vient de changer? C'est pourtant pas un pointeur!!

Quand je lis ceci, je trouve que des baffes se perdent. On n'appelle pas une fonction "fonction". Plus s�rieusement, bien que cela soit la m�me id�e, il est bon que le r�le de la fonction, et/ou ce qu'elle va faire de ses param�tres, transparaisse dans son nom. Au pire dans tous les cas, c'est document�.

Et puis on n'appelle pas une fonction sans savoir ce qu'elle fait, non ? Si dans la signature j'ai une r�f�rence non constante, je sais que le param�tre en en [out], voire [in,out]. Mais certainement pas en [in]. Et quand ce n'est pas le cas, j'ai tendance � faire savoir que c'est n'importe quoi et je remets les consts oubli�s.

En g�n�ral, j'ai des pointeurs bruts quand la s�mantique des op�rations mises en oeuvre le requiert.

[M�dinoc]

Et puis on n'appelle pas une fonction sans savoir ce qu'elle fait, non ?

J'ai jamais dit que c'�tait moi qui l'appelais... Quand tu regardes le code d'un autre et que tu essaies de le comprendre (surtout s'il n'est pas assez comment�) C'est pas �vident...

(quant � la signature de fonction, on n'a pas toujours une IDE qui l'affiche...)

[Aurelien.Regat-Barrel]

C'�tait un exemple je pense . Vu que souvent les fonctions sont mal nomm�es �a se d�fend. Si les pointeurs pouvaient lever l'ambiguit�, ce serait un plus. Si ils pouvaient... Car ton argumentaire ne tient pas:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

fonction(&a);        //Ah, un pointeur. S'il n'est pas const, il pourrait bien modifier...

il pourrait, mais on n'en sait rien, strictement rien. Pour �tre fix�, il faut aller regarder le prototype de fonction, si c'est

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

void fonction( const A * );

alors c'est pas modifi�, si c'est

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

void fonction( A * );

alors c'est certainement modifi�. Et avec les r�f�rences, c'est exactement la m�me chose. Si c'est

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

void fonction( const A & );

alors c'est pas modifi�, si c'est

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

void fonction( A & );

alors c'est certainement modifi�.
Donc les r�f�rence peuvent peut �tre dissimuler la modification d'une variable (si le nom de la fonction est mal choisi etc...), mais les pointeurs � l'inverse font syst�matiquement penser que la variable est modifi�e. Donc faut pas se fier � �a pour d�terminer si une var est modifi�e ou non.

[M�dinoc]

En effet, il ne faut pas forc�ment s'y fier. Mais le & encourage � regarder le prototype, alors que quand on vient comme moi du C, on n'a pas encore forc�ment le r�flexe de se dire "mince, �a pourrait bien �tre une r�f�rence, donc j'ai int�ret � regarder".
Quand en C, on regarde le code d'un autre avec des tas de fonctions, on n'a pas toujours le temps de faire �a...

Enfin, c'est un r�flexe suppl�mentaire � prendre. C'est toujours mieux que "int &b = a" (l'esprit humain a tendance � interpr�ter le code en "assume no aliasing"). On finit par s'y retrouver, mais je trouve les pointeurs plus explicites (malgr� leur inconv�nient de pouvoir �tre NULL en param�tre).

[Aurelien.Regat-Barrel]

on n'a pas encore forc�ment le r�flexe de se dire "mince, �a pourrait bien �tre une r�f�rence, donc j'ai int�ret � regarder".

Oui je comprend, je pensais �a aussi fut un temps. Maintenant je me dis que c'est pas sur ce m�canisme qu'il faut s'appuyer, mais sur des commentaires / choix judicieux de noms. En tous cas, je me souviens pas d'avoir �t� pi�g� � ce niveau. Par contre les pointeurs erron�s...

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
// initialiser A
A a;
if ( !read_from_config_file( a ) )
{
    // erreur
}
 
// afficher
print_infos( a );

ce genre de code parle de lui m�me je pense. Si print_infos a un effet de bord et modifie a, c'est que c'est mal fichu. Avec ce code:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

print_infos( &a );

si tu as le r�flexe d'aller voir le prototype de print_infos, je comprends pas pourquoi tu ne l'as pas avec la version sans pointeur.

[Luc Hermitte]

+1 � la r�ponse d'Aur�lien. Dans tous les cas il doit (*) y avoir des "const". Qu'il s'agisse de pointeur ou de r�f�rence.

En ce qui me concerne, les passages de param�tres se font par :
- r�f�rence-constante : "gros" objet en lecture seule
- r�f�rence : objet en lecture et/ou �criture
- valeur : "petit" objet en lecture seule ET qui dispose qu'une s�mantique de valeur en g�n�ral, ou juste copiable parfois seulement. (je ne suis pas trop un adepte de l'optimisation syst�matique propos�e par H.Sutter et A.Alexandrescu dans leur bouquin de qualit�)
- pointeur (brut ou intelligent) : pour les param�tres optionnels ou qui sont vraiment des pointeurs dont la responsabilit� doit migr�e ou �tre partag�e.

Je peux aussi garder des pointeurs quant il s'agit de r�f�rencer des objets dont on veut s'assurer que la dur�e de vie ex�de celle du r�f�rant.

(*) Et quant ils ne sont pas explicites, on perd une apr�s-midi � rendre const-correct ce qui ne l'est pas -- largement r�compens�, AMHA, par les doutes et les traques de bugs qui nous seront �pargn�s.

[hegros]

Bonjour

Avec �norm�ment de retard sur la discution, juste pour r�agir � ceci :

Sinon en codant en C ou C++ avec des biblioth�ques portables, on arrive � faire fonctionner un executable sur autant de plate-formes que Java

Oui mais cela n�cessite une recompilation. En java non.

[Jean-Marc.Bourguet]

Oui mais cela n�cessite une recompilation. En java non.

Ah, que fait la JVM ? :-)

[hegros]

Oui mais cela n�cessite une recompilation. En java non.

Ah, que fait la JVM ? :-)

Ca me semble plus souple pour le developpement.
De plus elle interprete du code ce n'est qu'apr�s qu'elle le compile et une seule fois biensur.

M'enfin y'a du pour et du contre comme toujours je suppose