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