Discussion :

[ChPr]

Bonjour à toutes et à tous,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void TinyGPS::get_position(long *latitude, long *longitude)
{
  if (latitude) *latitude = _latitude;
  if (longitude) *longitude = _longitude;
}

A quoi servent les tests "if (latitude)" et "if (longitude)" ? Cela sert-il simplement à savoir si les variables "latitude" et "longitude" existent vraiment, c'est-à-dire qu'elles ne pointent pas sur NULL.

Merci pour vos précisions.

Pierre

[Médinoc]

Cela sert en effet à tester si les pointeurs sont non-nuls (et donc, s'il est possible d'écrire sur leur destination sans danger).

Personnellement, bien qu'ayant longtemps été partisan de cette écriture, j'ai fini par comprendre qu'écrire explicitement if(pointeur != nullptr) donnait un code plus compréhensible; de nos jours je réserver if(valeur) aux valeurs réellement booléennes.

[ChPr]

Merci pour cette précision.

Dans un code où sont explicitement définies mes variables, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
TinyGPS gps;
 
long lat, lon;
...
gps.get_position(&lat, &lon);

je ne vois vraiment pas l'utilité de ce test.

Cordialement.

Pierre

[Médinoc]

Mais la fonction ne sait pas qu'elle ne va jamais être appelée avec des pointeurs non-nuls (à moins d'être private, auquel cas celui qui implémente la classe peut s'en assurer).

Il y a aussi la possibilité de passer les paramètres par référence plutôt que par pointeur, mais le passage par référence non-constante "silencieux" (i.e. avec la même syntaxe que le passage par valeur) de C++ me met mal à l'aise (quand je passe un int directement à une fonction, je ne m'attends pas à ce qu'elle le modifie). Je prèfère largement la syntaxe du C# à ce sujet, où le passage par référence est explicite.

[Pyramidev]

Cela me fait penser à l'article "Y a-t-il une raison pour laquelle les fonctions ne retournent qu'une seule valeur dans la plupart des langages de programmation ?"
Lien : http://www.developpez.com/actu/89847...agez-vos-avis/

Personnellement, je n'aime pas ce code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void TinyGPS::get_position(long *latitude, long *longitude)
{
  if (latitude) *latitude = _latitude;
  if (longitude) *longitude = _longitude;
}

La latitude et la longitude sont directement disponibles en tant que variables membres. Donc je ne vois pas de bonne raison que cette fonction existe au lieu d'être découpée en deux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
long TinyGPS::get_latitude() const // ne pas oublier const
{
    return _latitude;
}
 
long TinyGPS::get_longitude() const // ne pas oublier const
{
    return _longitude;
}

Pas de problème de pointeur nul.
Pas de problème de passage par référence non-constante "silencieux".

Et même si la latitude et la longitude n'étaient pas directement disponibles en mémoire mais le résultat d'un calcul lancé par la fonction TinyGPS::get_position, alors une solution aurait été que cette fonction retourne un objet contenant la latitude et la longitude :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
TinyGPS gps;
// ...
TinyGPS::Position position = gps.get_position();
long lat = position.get_latitude();
long lon = position.get_longitude();

[JolyLoic]

A quoi servent les tests "if (latitude)" et "if (longitude)" ? Cela sert-il simplement à savoir si les variables "latitude" et "longitude" existent vraiment, c'est-à-dire qu'elles ne pointent pas sur NULL.

Petit point de vocabulaire, à la limite du pinaillage, mais la réponse suivant me laisse penser qu'il y a peut être une légère confusion. Dans ta fonction, latitude et longitude existent, ce n'est pas une option. Et ce sont deux variables de type pointeur pointeur sur long. Le test a pour but de vérifier si ces pointeurs pointent sur de la vraie mémoire ou pas, ce dernier cas étant indiqué par la valeur conventionnelle nullptr.

Dans un code où sont explicitement définies mes variables, par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
TinyGPS gps;
 
long lat, lon;
...
gps.get_position(&lat, &lon);

je ne vois vraiment pas l'utilité de ce test.

Dans ce code globalement, le test ne sert à rien, et il est possible qu'un bon compilateur le supprime complètement. Mais la fonction get_position est susceptible d'être appelée dans d'autres contextes, où le test pourrait voir une utilité (même si je n'aime pas cette écriture, mais c'est un autre sujet...).

[foetus]

A quoi servent les tests "if (latitude)" et "if (longitude)" ? Cela sert-il simplement à savoir si les variables "latitude" et "longitude" existent vraiment, c'est-à-dire qu'elles ne pointent pas sur NULL.

Ce sont des simplifications C de tests 0, zéro - NULL - false

• if (XXX) { /**/ } équivaut à if (XXX != 0/ NULL/ false) { /**/ }
• if (!XXX) { /**/ } équivaut à if (XXX == 0/ NULL/ false) { /**/ }

[Pyramidev]

Dans ce code globalement, le test ne sert à rien, et il est possible qu'un bon compilateur le supprime complètement.

...à condition que la fonction TinyGPS::get_position soit en ligne.

[JolyLoic]

Certains compilateurs sont capable d'optimiser ça même si la fonction n'est pas inlinée. Ca s'appelle généralement whole program optimisation, ou link time optimisation. Ce qui revient en fait à prendre des décisions d'inlining à postériori. Là où ça résiste, c'est quand il y a une frontière de bibliothèque dynamique entre les deux (ce qui est une bonne raison de ne pas utiliser de .DLL/.so sauf là où c'est nécessaire).

[koala01]

Salut,

Il faut voir le cas d'utilisation réel de la fonction get_position, mais, si on s'attend à ce que l'utilisateur de cette fonction transmette forcément un pointeur aussi bien pour la longitude que pour la latitude (comprend : qu'il n'ait pas d'autre choix que de récupérer les deux de manière systématique), nous pourrions partir du principe que, lorsque l'utilisateur de la fonction ne transmet que la longitude (ou que la latitude, ou pire encore, aucun des deux), c'est forcément une erreur de programmation.

Il pourrait alors s'avérer intéressant d'utiliser carrément une assertion, afin que le mode debug nous indique clairement les appels à la fonction qui ne "respectent pas les règles". (note au passage que le passage par référence est aussi en mesure de nous apporter cette garantie)
Ainsi, nous pourrions très bien avoir quelque chose qui ressemblerait à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
void TinyGPS::get_position(long *latitude, long *longitude)
{
  assert(latitude!=nullptr && "No latitude destination");
  assert(longitude!=nullptr && "No longitude destination");
  *latitude = _latitude;
  *longitude = _longitude;
}

Mais bien sur, cela implique que... ni la longitude ni la latitude ne sont optionnelles

[bountykiler]

Euh, on est dans le forum C++ ici, donc utilisons ce que C++ nous offre.
Si on ne veut pas que les paramètres de la methode get_position puisse être des pointeurs NULL, il suffit d'utiliser des references et non des pointeurs.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
void TinyGPS::get_position(long &latitude, long &longitude)
{
  latitude = _latitude;
  longitude = _longitude;
}

et pour l'appel:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
TinyGPS gps;
 
long lat, lon;
...
gps.get_position(lat, lon);

(Après je suis d'accord, renvoyer ces 2 valeurs de la sorte c'est pas top, mais c'est un autre débat)

[koala01]

Euh, on est dans le forum C++ ici, donc utilisons ce que C++ nous offre.

Et en quoi ce que j'ai dit va-t-il à l'encontre de ce que C++ nous offre

Les assertions représentent bel et bien une fonctionnalité proposée par le C++ et qui s'avère, en outre, particulièrement intéressante lorsqu'il est question de vérifier les préconditions (les conditions dont le respect ne dépend que du développeur

Si on ne veut pas que les paramètres de la methode get_position puisse être des pointeurs NULL, il suffit d'utiliser des references et non des pointeurs.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
void TinyGPS::get_position(long &latitude, long &longitude)
{
  latitude = _latitude;
  longitude = _longitude;
}

et pour l'appel:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
TinyGPS gps;
 
long lat, lon;
...
gps.get_position(lat, lon);

Dans l'absolu, tu as raison (je l'avais dailleurs signalé)... Mais il faut garer en tête que nous parlons d'une bibliothèque qui a toutes les chances d'être dynamique, et donc qui a toutes les chances de vouloir aussi être utilisée en C.

Je verrais donc bien une fonciton extern C proche de getPosition(Gps * , int * latitue, int * longitude) qui pourrait servir de glue à tout le fatras, mais utilisant obligatoirement des pointeurs pour la simple et bonne raison que... les références n'existent pas en C.

Et, dans ce cas, l'existence de la longitude et de la latitude devrait être garantie, ne crois tu pas

[bountykiler]

Effectivement, si cette méthode a pour vocation d'être utilisée dans du code C, alors on est contraint d'utiliser des pointeurs et donc ces assertions prennent tout leur sens.
Sinon déso, j'avais pas vu ta remarque concernant les références .