Discussion :

[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

[Invit�]

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.

Quoi ?

Un programme �crit en C/C++ doit �tre recompil� pour marcher sur une autre plate-forme. Mais cela peut-�tre fait simplement par ex�cution d'un makefile... En ce point, �a ne dif�re pas beaucoup de la JVM, simplement un temps d'attente et puis apr�s c'est parti (et pas besoin de recompiler � chaque fois).
Non, je trouve que si on peut qualifier le java de "portable", alors le C/C++ a aussi droit � cette d�nomination.

Par contre, il est vrai qu'il y a des diff�rences de vitesse (parfois n�gligeables) entre le C/C++ et le java, et qu'elles existeront toujours (le java est trop �loign� du syst�me, notament avec les pointeurs qui sont (mal) camoufl�s (mais on peut faire la m�me remarque pour les r�f�rences en C++)).

[gege2061]

Non, je trouve que si on peut qualifier le java de "portable", alors le C/C++ a aussi droit � cette d�nomination.

On parle de portabilit� au niveau des sources, je trouve que �a refl�te bien la chose.

[Newgaia]

slt,
Je reprendra ce qui a �t� pour plus d'emphase, Tu peux �crire oo en C.

En n'oublies pas Java bien et C tant mieux

[davcha]

Non, je trouve que si on peut qualifier le java de "portable", alors le C/C++ a aussi droit � cette d�nomination.

La JVM est standard. Le C/C++ peut l'�tre �galement, mais assez souvent on se retrouve face � un makefile qui d�conne parce que :
- pas le m�me compilo
- librairies pas standard utilis�es dans le programme � compiler
- non respect de la norme (� mettre en rapport avec "pas le m�me compilo")
...

Bref, le java est certainement plus portable que le C/C++, parce qu'il y a quand m�me un nombre non n�gligeable de programmeurs qui font plus ou moins n'importe quoi ou se moquent de la portabilit� de leur code.

[Matthieu Brucher]

C'est s�r que l'avantage du Java, c'est que �a tourne sur n'importe quoi - il faut juste toute la JVM pour �tre s�r, ce qui n'est pas le cas sur nombre d'impl�mentations - et il existe m�me des processeurs qui traitent directement le byte code Java.
Mais dire que le C/C++ n'est pas portable...
Java est portable, mais l'inconv�nient majeur, c'est que c'est Java qui fait le pont entre les diff�rents syst�mes quand c'est au programmeur de le faire en C/C++ - GUI, r�seau, thread, ... -, ce qui fait que m�me si Java �tait compil� comme le C/C++, il serait plus lent.

[Luc Hermitte]

La JVM est standard.

Non, il y a un monopole de sun et une sp�cification dont ils sont les seuls maitres. Ce devient beaucoup plus facile pour mettre tout le monde d'accord.

Code :

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

1
2
Le C/C++ peut l'être également, mais assez souvent on se retrouve face à un makefile qui déconne parce que :
- pas le même compilo

aap, bjam, scons, etc sont nos amis

Code :

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

- librairies pas standard utilisées dans le programme à compiler

Ca quand les gens se fichent du portable, ou sont mal �duqu�s, on n'y peut rien. Et Java n'est pas �pargn� non plus. Cf ce qui s'�tait pass� avec OOo

Code :

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

- non respect de la norme (à mettre en rapport avec "pas le même compilo")

Il faut mettre � jour ses compilos. De la m�me fa�on, un code qui utilise les g�n�rics ne fonctionnera pas en Java 1.4


Le troll initial ce n'�tait pas C vs C++ ?