08:00 Mot de passe oublié ?

30

nEUrOO :
Les références ne posent aucun problèmes mais ont des limites, c'est tout... quand aux pointeurs en C++, ils ont uniquement été conservés parceque C++ devait intégrer C.

Euh, tes deux phrases sont pas un peu contradictoires là ? trifus
Et la deuxième est nettement exagérée : les références ne sont, justement, pas modifiables, du coup elles ne conviennent pas dans un paquet de situations (par exemple tu ne peux pas les mettre dans un std::vector ^^). Evidemment, ça aurait pu être fait via une classe de la STL plutôt qu'avec un type built-in, mais ça n'aurait pas changé grand-chose smile

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

31

Par reference on ne peut pas savoir explicitement si la variable est suceptible d etre modifiée... Un peu génant pour lire le code!!!
(C est pour cela que beaucoup de programmeurs preferent utiliser le pointeur).
De plus je ne suis pas fana des truc de ce genre:
void FuckingFunction(int &FuckingReference = *static_cast<int*>(NULL));
Sans compter que les références comme le souligne Pollux ne sont que des identificateurs. Le pointeur est une déclaration de variable (ok ca a une petite difference de cout...). Mais la référence est fixée elle, et cela limite donc son utilisation.
En gros les ref sont souvent utilise en const ref, ce qui evite l ambiguité précisée au debut de ce poste.

32

JackosKing
: Par reference on ne peut pas savoir explicitement si la variable est suceptible d etre modifiée... Un peu génant pour lire le code!!!
Tu n'as qu'à considérer qu'elle est tout le temps suceptible de le faire. En général ça ne pose pas de pb.
Mais si tu restes trop perturbé, sache que :
1. Tu manipules souvent des références vers des objets constant (que tu as reçu en paramètre), donc tu ne peux pas appeler de méthode sur eux qui les modifie.
2. Tu peux toujours faire une pirouette du genre :
const MonObjet& const_objet = objet;
Et ensuit utiliser const_objet dans tes appels pour être sûr qu'il ne sera pas modifié.
(C est pour cela que beaucoup de programmeurs preferent utiliser le pointeur).
Tu n'as pas l'air de connaître le langage C non plus : quand on passe l'adresse d'un objet, on ne sait pas non plus s'il va être modifié... On peut jouer avec des const, mais ça revient au même que ce que je t'ai dit plus haut...
En gros les ref sont souvent utilise en const ref, ce qui evite l ambiguité précisée au debut de ce poste.
Bah où est le pb alors ?
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

33

1. Les pirouette je les laisse aux programmeurs crades... Quand a ta remarque, tu te bases dans le cas particulier ou on a un prototype avec const.
2. Ne t inquiette pas niveau C, C++ je me debrouille plus que bienwink
3. Justement si tu relis mon poste tu veras que tout tiens la route. Utilisation des references uniquement en const, pour le reste pointeur est a mon sens une programmation bien plus propre.

34

Au fait ca deviens lassant de voir des arguments du genre tu ne t y connais pas tres bien...
Je pense que si tu relisais deux fois mon poste tu pourais te passer de ces commentaires.

35

Un pointeur, c'est par définition moins propre qu'une référence dès lors que tu passes un objet. Un pointeur sert à passer une adresse, point.
En terme de sémantique :
référence => c'est l'objet qui intéresse la fonction
pointeur => c'est l'adresse qui intéresse la fonction

Bon maintenant je comprends pas ce qui te parait pas clair dans une déclaration comme :
bool apply_foo(bar &);C'est pourtant clair : la fonction prend un objet bar en paramètre et est susceptible de le modifier. Je vois pas où il peut y avoir de confusion ?

Au passage, il y avait un truc que j'ai noté plus haut, je sais plus qui disait ça, mais 
bool foo(bar);
et
bool foor(const bar &);
Ne sont pas équivalents, sur de nombreux aspects.

36

JackosKing
: 1. Les pirouette je les laisse aux programmeurs crades...
C'est où que c'est crade ?
Quand a ta remarque, tu te bases dans le cas particulier ou on a un prototype avec const.
Je ne te suis pas, tu parles de quelle remarque précisément ?
2. Ne t inquiette pas niveau C, C++ je me debrouille plus que bienwink
OK tritop
3. Justement si tu relis mon poste tu veras que tout tiens la route. Utilisation des references uniquement en const, pour le reste pointeur est a mon sens une programmation bien plus propre.
Je ne vois pas en quoi c'est plus propre trifus
C'est juste une convention qui ne te permet pas de profiter de l'avantage syntaxique offert par les références, en général plus agréables à manipuler que des pointeurs.
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

37

Pour moi tout est clair, c est une question de lisibilité de code. Il ne faut pas oublier que dans 99% des cas ton code dans une entreprise sera repris par qqn d autre.

38

Le code dans une entreprise ça existe plus en France, sauf quelques niches isolées.

Ceci dit, oui c'est une question de lisibilité du code. L'utilisation de référence offre des *garanties* que l'utilisation de pointeurs n'offre pas :
- aucune manipulation d'adresse ne peut être faite
- la référence ne peut pas être réassignée
- la référence ne peut pas être nulle
- il n'est pas possible de la caster par mégarde comme un pointeur
- elle a une sémantique "propriétaire" clairement définie : celui qui possède la référence n'est pas propriétaire de l'objet.

Tout ceci évite l'écriture de nombreux bugs.

39

Je suis pas en France wink
Et mes arguments sont partagés dans l entreprise ou je suis car on a cette contrainte d'écriture.
Apres que l on ait pas le meme avis dessus, c est tout a fait comprehensible :P

40

JackosKing :
De plus je ne suis pas fana des truc de ce genre: void FuckingFunction(int &FuckingReference = *static_cast<int*>(NULL));

Euh, ça n'est pas du tout valide ça je crois...

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

41

A vérifier :P

42

Non ce n'est pas du tout valide wink
Mais je comprends pourquoi tu n'utilises pas les références du coup grin tongue

43

{sabatier.xxxx}[160] cat *.cpp && g++ *.cpp && ./a.out 
#include <iostream>

using namespace std;

char FuckingFunction(int &FuckingReference = *static_cast<int*>(NULL))
{
        return &FuckingReference?FuckingReference+'0':'X';
}

int main(int uArgs, char **pArgs)
{
        cout << "yEp dah Fuckoff fucking rEfereNCe" << endl;
  cout << "yOp what that? -> " << FuckingFunction(++uArgs) << endl;
  cout << "yOp what that? -> " << FuckingFunction() << endl;

        return 0;
}
yEp dah Fuckoff fucking rEfereNCe
yOp what that? -> 2
yOp what that? -> X
{sabatier.xxxx}[161]

44

Ce code n'est pas valide.
Qu'un compilateur l'accepte on s'en fout.
Les compilateurs acceptent bien des horreurs, ça n'en fait pas du code valide pour autant.

45

./43> Tu remarqueras que c'est surtout l'utilisation des pointeurs qui est dangereuse.
avatar
« Quand le dernier arbre sera abattu, la dernière rivière empoisonnée, le dernier poisson capturé, alors vous découvrirez que l'argent ne se mange pas. »

46

Valide selon quelle norme pour toi?
Cette notation il me semble que je l avais apprise dans un vieux bouquin de C++ #gné#

47

Selon la norme ISO. Tu connais beaucoup d'autres normes pour le C++ ?

Rien que :
*static_cast<int*>(NULL)
Ici tu déréférences un pointeur nul. Le comportement est au mieux indéfini, au pire c'est interdit par la norme (je me souviens pas). Note que le problème vient de ce que c'est un pointeur. Avec des références tu n'aurais pas pu écrire une chose pareille.
int &FuckingReference =
Cette opération est interdite : un paramètre passé par référence sans modifieur const doit impérativement être une l-value.
return &FuckingReference?FuckingReference+'0':'X';
Ce code est valide, mais il est strictement équivalent à
return FuckingReference + '0';



De manière assez amusante, tous les problèmes de ton exemple foireux ont pour origine le pointeur, et le fait que gcc soit un peu trop permissif et te laisse convertir le pointeur nul en référence, ce qui est illégal tongue

48

spectras
:
return &FuckingReference?FuckingReference+'0':'X';
Ce code est valide, mais il est strictement équivalent à
return FuckingReference + '0';

Ou, plus précisément, ce n'est "strictement équivalent" que si le programme ne viole pas la norme : le fait que ces deux expressions ne soient pas équivalentes dans l'exemple de JackosKing montre que son programme est invalide ^^

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

49

il y a moyen d avoir la grammaire ISO du C++ ? Enfin un lien parce que je la trouve pas #flemme#

50

euh ça n'a rien à voir avec la grammaire ça trifus

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

51

Bein je ne comprend pas pourquoi, la grammaire n est pas sencé définir justement le droit ou non des opérations comme : int &FuckingReference =?
Enfin c est pourtant ce que je pensais quand j ai fait mon projet de technique de compilation triso

52

En effet, ce n'est pas la grammaire. Tiens, une citation de la norme, qui semble avoir été spécialement écrite pour toi, JackosKing :
a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior.

53

./51>
La grammaire définit que "int &" est un type de données, que "FuckingReference" est le nom de la variable que tu déclares, que "=" est le séparateur entre le nom de variable et sa valeur initialisée, etc... Mais elle ne dit pas ce qu'il faut faire quand on initialise une variable, qu'on calcule une addition ou qu'on déréférence un pointeur : ça c'est la sémantique ^^ Bref, du point de vue grammatical, ton code est correct (sinon de toute façon il ne compilerait pas), c'est du point de vue sémantique que ça foire...

Et, je vais sûrement t'étonner en te disant que la sémantique (ou la grammaire, d'ailleurs) de C++ est décrite dans, oh surprise, la norme C++ triso

« The biggest civil liberty of all is not to be killed by a terrorist. » (Geoff Hoon, ministre des transports anglais)

54

Ok.
Mon cours de technique de compilation etait qu une introduction sad

Bon bein pour mon code il semble alors foireux (faudra que je retrouve ce bouquin...).
Mais bon sinon mon avis sur l utilisation des references n a pas changé:P

55

Mais bon sinon mon avis sur l utilisation des references n a pas changé:P
Vu comment tu utilises les références ça m'étonne pas en même temps. Apprends à les utiliser avant. Ce ne sont pas des pointeurs hein. Ca fonctionne différemment, ça s'utilise différemment. Tu viens de le prouver par un magnifique exemple tongue

56

Ceci etant dit l exemple aurait ete avec un objet ok, mais NULL est quand meme un token a part :/ donc il etait possible de le gerer par la grammaire non (apres vive la grammaire super compliquée:P)?

57

Non, ton exemple doit être totalement repensé. Il est construit sur un modèle à pointeurs, disposant d'une valeur pour représenter l'invadilité d'une adresse. Ceci n'est pas compatible à un modèle à références.

Le plus proche que tu aurais pu faire c'est ça => 
char FuckingFunction(int &FuckingReference) 
{ 
        return FuckingReference+'0';
} 
char FuckingFunction() 
{
        return 'X';
}

58

Vu comment tu utilises les références ça m'étonne pas en même temps. Apprends à les utiliser avant. Ce ne sont pas des pointeurs hein. Ca fonctionne différemment, ça s'utilise différemment. Tu viens de le prouver par un magnifique exemple

-> Oui enfin l exemple est un cas bien particulier...
En meme temps l utilisation que j en fait est en partie normalisee (puisque tu aimes bien ce mot) par mon entreprise.
Et la dessus ils sont assez chian (enfin surtout mon boss), mais je suis plutot d accord avec eux.
Point de vu lecture du code:
int i=3;
fonction(i);
if(i)...
Il faut aller voir obligatoirement le prototype pour savoir si c est une reference ou non.
C est bien dans de petits projets, mais apres ca devient vite inchiable...
Alors oui on adopte la technique du const & ou pointeur. Et on est pas les seuls a l utiliser.
Pourquoi? parce que la relecture du codes est beaucoup plus simple au niveau de la comprehension ( c est un avis, libre d avoir chacun le sien).

59

int i=3;
fonction(i);
if(i)... Il faut aller voir obligatoirement le prototype pour savoir si c est une reference ou non.
Et alors ?
1) le nom de la fonction devrait être explicite.
2) de toutes façons, si i était un objet et pas un entier, tu serais quand même obligé d'aller voir. Pour deux raisons :

1) Parce qu'avec un objet tu ferais 
object i = truc;
i.fonction();
if (i)...
Et tu ne coupes pas, donc, si la fonction n'est pas explicite, à aller regarder la déclaration, qui peut être 
void  fonction();
void  fonction() const;


2) Parce que tu pourrais avoir des membres mutables dans l'objet, et là c'est la sémantique de la classe qui définira si oui ou non la modification de ces membres mutables affecteront l'opérator bool(). Habituellement non, mais ce n'est pas techniquement impossible.

60

Tiens, je n'avais pas trop vu ce topic...

Bon, alors:
Pendant longtemps, en tant qu'originaire du C, je préférais utiliser les pointeurs, sauf quand les références étaient indispensables, surtout à cause du &.
J'avais un peut de mal à réaliser que: 
int a;
fonction(a);

pouvait modifier a.

Depuis, j'ai évoluer, et j'utilise les pointeurs pour les paramètres facultatifs (une référence n'est pas supposée être NULL) ou les fonctions new-like.
avatar
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.
Aide Charte Contacts Crédits Réalisé avec yAronet 66 ms