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