Error de conception ou pas ? - template - reinterpret_cast - exceptions

Bonjour,

je suis sur un projet embarqué où je n'ai pas la STL ni la gestion des exceptions.
J'ai besoin d'avoir des listes doublement chaînées. Je suis donc en train de me créer une liste doublement chaînée (DLList<T> pour moi).

Mon code est quasi terminé et donc maintenant avec je le test et j'en suis à la partie où je teste les itérateurs.

Mon test actuel est le test de

Code:

---

1 2 3 4 5 6 7 8 9 10

//! Returns reference to value in iterator's target, //! @todo : BIG problem if m_Position = NULL, should throw an error inline T& operator*() const { if(m_Position != NULL) return m_Position->val; else return *(reinterpret_cast<T*>(NULL)); // should throw an error }

---

Si pour une raison inconnue l'itérateur pointe sur NULL, alors je fais quoi ?
C'est carrément crade de faire une référence sur NULL non ? Que suggérez-vous ?

Ce que tu fais est interdit (déréférencer NULL).

Ton problème est un problème de contrat : ton itérateur doit être déréférençable pour que * soit appelé.

Suivant le contexte, il n'y a pas de solution magique. Si tu n'as pas le droit aux exceptions, il faut t'arranger pour pouvoir faire une erreur autrement (code d'erreur et paramètre par réf, par exemple...)

À noter que pour moi, tu ne devrais pas gérer ce cas : le bug est dans l'appelant, qui doit vérifier que l'itérateur est déréférençable avant d'appeler *.

Le chef de projet n'a pas prévu de gestion des erreurs non plus :aie:

donc dans mon cas je fais :

Code:

---

1 2 3 4 5 6 7 8

inline T& operator*() const { //if(m_Position != NULL) return m_Position->val; //else // return *(reinterpret_cast<T*>(NULL)); // should throw an error }

---

Pour ce qui est du dé-référencement de NULL, la réponse est ici.

Comment l'appelant peut-il vérifier que l'itérateur est déréférencable ?

Citation:

---

Comment l'appelant peut-il vérifier que l'itérateur est déréférencable ?

---

C'est a toi de lui fournir un moyen de le faire. Dans la stl, par exemple, on compare avec .end()

Bon par contre, je ne suis pas ton chef de projet et peut-être a-t-il une vraiment bonne raison de faire comme ça, mais réimplémenter la stl plutôt que l'utiliser...

à noter que tu peux aussi écrire ton code comme ça :

Code:

---

1 2 3 4 5

inline T& operator*() const { assert(m_Position != NULL); return m_Position->val; }

---

et lire http://julien-blanc.developpez.com/a...rat_cplusplus/ pour en savoir un peu plus sur les contrats, et avoir une solution plus modulable pour gérer les violations de contrat.

je suis d'accord avec toi, on en a déjà parlé depuis longtemps que la STL est indispensable mais bon ... pas moyen, ni même uSTL pour des raisons de "performances" ... Forcément, quand le chef est un linux boy qui court toujours à la performance même lorsqu'il a des marges énormes ...

Au final je laisse l'appelant se démerder, j'ai utilisé des sentinelles dans ma liste donc l'appelant peut effectivement s'en servir et à moi de la retourner si la position = NULL ou tout simplement d'initialiser l'itérateur à end() et me débrouiller pour qu'aucune opération ne puisse amener l'iterateur autre part que à end().