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().