Discussion :

[oodini]

Hello,

Disons que j'ai une classe dotée d'un énorme vecteur d'instances d'une structure (consécutive à la lecture d'un fichier).
Je veux donner un accès en lecture seule aux éléments de ce vecteur en fonction d'un indice.

L'encapsulation me prescrit d'utiliser pour cela une fonction.

Dans le code sur lequel je bosse, cela est fait avec une fonction prenant une argument une référence, et qui a comme valeur un booléen qui renvoie false si l'indice était en dehors des bornes du tableau.
Le false est renvoyé si en interne, on a levé l'exception std::out_of_bound (en testant l'indice par rapport à la taille du vecteur).

Inconvénient :
L'argument en référence impose de construire au préalable un objet, dont les membres sont settés avec la valeurs de l'élément recherché s'il est trouvé

Avantage :
Du point de vue du client de la fonction, la valeur de retour est plus facile à gérer qu'une exception


L'autre solution serait simplement d'avoir une fonction qui renverrait la référence vers l'élément recherché.

Inconvénient :
Le client doit gérer les exceptions.

Avantage :
Pas de construction superflue d'objets.


Une troisième solution serait de renvoyer un pointeur (intelligent) qui pourrait être nul.


Quelle solution a votre préférence ?

[jblecanard]

Salut !

Je vois au moins deux autres solutions :
- Retour d'un pointeur, nullptr si l'élément n'est pas trouvé, pointeur vers l'objet s'il est trouvé (avec la constness s'il le faut).
- La même chose, mais avec boost::optional qui contient une référence.

[Médinoc]

Si c'est pour une classe généraliste, les tableaux associatifs de .Net offrent les deux:

• Un opérateur [] qui retourne directement l'objet indexé, et lance une KeyNotFoundException en cas d'échec.
• Une fonction bool TryGetValue(TKey key, TValue & value)

Et c'est l'utilisateur qui choisit.

Note: La version TryGetValue ne fait pas de "on appelle la version qui plante dans un try/catch", car c'est couteux en performance et ça pollue le debugger.

[JolyLoic]

Puisqu'on parle philosophie, philosophons...

Quelle est la signification d'un accès hors limites à ton tableau ? Est-ce une situation normale (par exemple, tu tentes d'accéder à l'élément de degré 15 d'un polynôme du second degré, c'est légitime et ça doit retourner 0) ? Est-ce une situation d'erreur liée à l'environnement (j'ai du mal à trouver un exemple, imaginons que le tableau est automatiquement descendu sur disque pour économiser la mémoire, et que là, au moment de le remonter, problème réseau) ? Est-ce une situation d'erreur liée à un bug (l'utilisateur de la classe a mis un +1 dans une boucle, il a oublié de valider des valeurs venant de l'IHM...) ?

Ces trois situations différentes méritent pour moi des réponses différentes. La première ne mérite pas grand commentaire, la solution apparaît généralement d'elle-même.

Pour la seconde, je choisirais une des réponses que tu as proposées. Le choix entre exception et code de retour serait probablement lié à la fréquence du problème, et à la distance entre l'endroit où le problème est détecté (accès à l'élément) et celui où il pourra être traité (affichage à l'utilisateur, reprise sur erreur, arrêt propre du programme...).

Pour la troisième (qui est à mon avis la plus courante dans ce genre de situation), prendre une solution comme tu proposes me semblerait mauvais (voir par exemple http://www.open-std.org/jtc1/sc22/wg...2013/n3604.pdf qui détaille ce point de vue, même si je ne suis pas forcément 100% en accord). Je mettrait simplement des asserts pour détecter le problème pendant les phases de test et l'éradiquer tant qu'il est temps. Éventuellement (mais je ne suis pas sûr de moi sur ce coup, je n'aime pas cette solution, je n'ai juste pas grand'chose de mieux à proposer), une exception en release si l'accès au tableau n'est pas critique en perfs.

[oodini]

J'ai plusieurs fichiers qui sont des transpositions de tables de bases de données. Et dans certains fichiers, certains champs correspondent à des indices vers d'autres tables (numéros de lignes dans d'autres fichiers).

Donc, théoriquement, il ne devrait pas y avoir d'erreur, si les données sont cohérentes. À moins que l'utilisateur de la fonction fournisse autre chose que l'indice attendu... Si problème il y a, cela devrait être visible en debug/tests. Donc, effectivement, un assert pourrait suffire.

Et l'application est critique en perfs, d'où mon souhait de refactorisation.

Je suis en tout cas rassuré de constater qu'il n'y a pas de réponse toute faite.