eviter les pointeurs NULL

Ce thread est un fork de cette discutions http://www.developpez.net/forums/sho...d.php?t=592996.


Je code avec des restrictions très fortes, via des invariants garantis de préférence par le typage, limitant ainsi fortement la nécessité de tout tester.

Citation:

---

Envoyé par loufoque

Je code avec des restrictions très fortes, via des invariants garantis de préférence par le typage, limitant ainsi fortement la nécessité de tout tester.

---

Cela semble intéressant mais j'ai quelques difficultés à me représenter cela.
Vous pourriez donner un exemple simple?
- W

Je n'utilise que des objets qui ne peuvent jamais être vide ou dans un état invalide et ceci avec une sémantique valeur.

Citation:

---

Envoyé par loufoque

Je n'utilise que des objets qui ne peuvent jamais être vide ou dans un état invalide et ceci avec une sémantique valeur.

---

Salut, tu aurais un exemples ou un lien de ce que tu parle???
J'ai dû mal à comprendre... :cry:

Je poursuis la remarque de loufoque:

Citation:

---

Envoyé par loufoque

Je n'utilise que des objets qui ne peuvent jamais être vide ou dans un état invalide et ceci avec une sémantique valeur.

---

Ce qui, en C++, signifie:
* code résistant aux exceptions
* RAII
* type safety (ce qui permet une récupération d'une bonne partie des erreurs logique au moment de la compilation)
* utilisation de la librairie standard

Et autres techniques dont le but est de maximiser la validité du code. Le Saint Graal étant d'arriver à un code qui ne peut compiler que si il est correct (ce qui n'est pas prêt d'être le cas, mais en s'arrangeant bien, on peut déja obtenir des choses sympas en C++).

Citation:

---

Envoyé par Emmanuel Deloget

Je poursuis la remarque de loufoque:

Ce qui, en C++, signifie:
* code résistant aux exceptions
* RAII
* type safety (ce qui permet une récupération d'une bonne partie des erreurs logique au moment de la compilation)
* utilisation de la librairie standard

Et autres techniques dont le but est de maximiser la validité du code. Le Saint Graal étant d'arriver à un code qui ne peut compiler que si il est correct (ce qui n'est pas prêt d'être le cas, mais en s'arrangeant bien, on peut déja obtenir des choses sympas en C++).

---

Ce sont de bons principes de programmation: ils permettent de prévenir des aberrations dans les cas "limite" souvent difficiles à provoquer via des tests.

Je ne pense pas qu'on puisse s'assurer que ces principes aient été respectés sans faire une revue du code.
Et malheureusement coder proprement ne signifie pas toujours que çà fera "papa, maman" comme on l'attend :cry:

- W

Citation:

---

Envoyé par wiztricks

Ce sont de bons principes de programmation: ils permettent de prévenir des aberrations dans les cas "limite" souvent difficiles à provoquer via des tests.

Je ne pense pas qu'on puisse s'assurer que ces principes aient été respectés sans faire une revue du code.
Et malheureusement coder proprement ne signifie pas toujours que çà fera "papa, maman" comme on l'attend :cry:

- W

---

Non, franchement, respecter ces principes est très simple en C++, et ça se contamine très facilement à tout code qui vient se baser sur ça.

Une classe dont tous les membres respectent le RAII respecte RAII, résiste aux exceptions.
Et pour que tous ses membres respectent le RAII, s'aider de la librairie standard si besoin.

----

Bon et sinon, j'suis déçu, personne n'essaie un minimum de garantir les invariants de la classe, en spécifiant à la main et en faisant quelles implications logiques ?

Pour des objets dont l'implémentation est compliquée bien, pas pour un p'tit Timer à la con.

Un pointeur, par exemple, ça peut être nul.
Un pointeur de fonciton, ça peut être nul.
Un Boost.Any, ça peut être nul.
Un Boost.Function, ça peut être nul.

Un objet dans un état nul invoque soit un comportement indéfini, soit une erreur, soit une exception.
Des choses que je tiens à éviter entièrement par conception.

En fait je fais de même, je les evite.

Sauf quand j'en ai besoin :)
Quand la logique du programme implique une absence d'objet référé, c'est naturel d'utiliser un pointeur. Comme c'est dans la logique du programme, ça doit être géré. Et par là même, l'etat nul n'est jamais une erreur, si il est permis.

Enfin dans l'idéal du moins.

Dans le cas d'un objet optionnel, j'utilise un wrapper de type boost::optional<T> ou de type boost::variant<T, null_type>.

Tout comme Some of 'a | None en ML ou le Maybe monad en Haskell.

C'est tout de même souvent une erreur de conception que de devoir travailler avec des objets qui peuvent être nuls.

Citation:

---

Envoyé par loufoque

Dans le cas d'un objet optionnel, j'utilise un wrapper de type boost::optional<T> ou de type boost::variant<T, null_type>.

Tout comme Some of 'a | None en ML ou le Maybe monad en Haskell.

C'est tout de même souvent une erreur de conception que de devoir travailler avec des objets qui peuvent être nuls.

---

boost::optional<T>, j'aime pas trop, la valeur est ajoutée est pas énorme, dans le sens où le typage ne te force pas à vérifier si l'objet est nul ou non.

Alors qu'à l'inverse boost::variant<T, null_type> ou le type Option de ML t'oblige à vérifier si l'objet est valide.

Citation:

---

C'est tout de même souvent une erreur de conception que de devoir travailler avec des objets qui peuvent être nuls.

---

Je ne vois pas en quoi?

Le cas le plus courant sur le quel je tombe est simplement quand on a besoin de savoir quel objet on a a un moment, ou si on a pas d'objet.
Par exemple une icone selectionnée ou aucune selectionnées, sont des etats valides dans beaucoup d'application (je pense principalement aux jeux vidéos là ou c'est très courant).
De même dans les bases de données il est souvent utile d'indiquer que l'information est manquante par une valeur nulle (qui est différente d'un texte vide par exemple).

A mon humble avis, remplacer systématiquement ce genre de logique par un objet est souvent overkill comme on dit, même si il ya des cas où c'est pertinent, ça ne semble pas l'etre pour tous les cas. D'ailleurs, ça n'aide pas forcément à la compréhension en travail d'équipe (quand toute l'équipe ne connais pas boost et n'a pas le temps de s'y mettre par exemple). Autant se servir des mécanismes de base du language.

Le cas des champs nuls dans une base de données est un cas courant, oui.
Après l'histoire des icônes j'ai pas compris. Un objet icône, une fonction is_checked et voilà...

Ah ben non is_checked suppose que tu vas parcourir un certain nombre d'icones pour voir laquelle est checkée/selectionnée. Je parlais d'un cas ou tu ne peux en avoir qu'une seule a la fois ou pas du tout.

C'est correcte logiquement, mais pas du poitn de vu des perfs! (surtout
De plus, tu as toujours le risque d'arriver a un état ou plusieurs icones sont selectionnées en même temps, or si ce n'est pas le comportement voulu (une seule maximum) c'est potentiellement un probleme.

En fait mon exemple n'est pas clair.
Imaginons que je fasse un petit jeu où on a une représentation de la main droite du héros. Cette main ne peut tenir qu'un seul item a la fois pour l'utiliser, ou pas d'item du tout. Chaque item est différent et unique et possède un pouvoir activé dés que le joueur le met dans la main du heros (une methode appliquant le pouvoir, appelée régulièrement).
Tu as globalement deux manières de faire la partie qui permet de savoir quel objet on a dans la main (pour pouvoir appeler sa methode de pouvoir) ou qu'il n'y a pas d'objet dans la main :
a) utiliser un identifiant (par exemple un index) et déclarer une valeur de cet identifiant qui corresponds à "pas d'objet".
b) utiliser un pointeur vers l'objet en question, si il est a null alors il n'y a pas d'objet dans la main.

En fait, c'est la même solution, sauf que a) nécessite de coder quelque chose qui est déjà là au final dans le language. De plus a) t'oblige a connaitre dans le code appelant la façon dont sont organisés les objets item. Même si le code est minime, c'est le même principe.
Autant utiliser b) dans ce cas là par exemple.

Pareil, utiliser un type qui rend explicitement optionnel le truc est bien plus sûr que des pointeurs.

Je sais que c'est un peu hors sujet, mais je n'ai pas encore trouvé d'explication suffisament convaincante de cette affaire liée aux pointeurs NULL (comme quoi, avoir à en gérer serait un code smell...). Est-ce que quelqu'un maitrise bien le sujet ?

Citation:

---

Envoyé par loufoque

Pareil, utiliser un type qui rend explicitement optionnel le truc est bien plus sûr que des pointeurs.

---

Si je comprend bien ce que tu dit, tu as toujours un objet qui correspond au NULL ‽
En gros un objet non initialisé que tu peut tester.
Alors quel différence avec le teste d'un pointeur à 0 ؟

Citation:

---

Envoyé par Mongaulois

Si je comprend bien ce que tu dit, tu as toujours un objet qui correspond au NULL ‽
En gros un objet non initialisé que tu peut tester.
Alors quel différence avec le teste d'un pointeur à 0 ؟

---

Cf mon message plus haut... http://www.developpez.net/forums/sho...3&postcount=11

Boost.Variant t'oblige à distinguer à la compilation les deux cas, null ou pas, si tu l'utilises avec le visiteur qui va bien.

> http://www.boost.org/doc/libs/1_35_0...l/variant.html

Contourner le système de type ne compte pas évidemment... Dans ce cas là, rien n'est plus sûr du tout en C++. Utiliser la fonction membre get<>() contourne le typage...

-----

Bien sûr, je considère que Boost.Variant reste du hack, pour construire du pattern-matching à la sauce ML, et ça reste assez lourd pour des utilisations simples.

Par contre, pour des structures arborescentes, c'est pas mal. Je l'ai utilisé pour faire un Abstract Syntax Tree une fois, on se croirait en OCaml.

Citation:

---

Bien sûr, je considère que Boost.Variant reste du hack

---

Il faudra m'expliquer en quoi...
C'est simplement

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

template<typename F> typenane F::result_type visit(const F& f) { switch(type) { case 0: return f(*static_cast<Type0*>(value)); case 1: return f(*static_cast<Type1*>(value)); ... } }

---

Un objet dont le type est obfusqué, un entier qui identifie de quel type il s'agit, et un switch pour reconvertir l'objet obfusqué vers l'objet typé.
Rien de magique.

Citation:

---

Envoyé par loufoque

Il faudra m'expliquer en quoi...
C'est simplement

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

template<typename F> typenane F::result_type visit(const F& f) { switch(type) { case 0: return f(*static_cast<Type0*>(value)); case 1: return f(*static_cast<Type1*>(value)); ... } }

---

Un objet dont le type est obfusqué, un entier qui identifie de quel type il s'agit, et un switch pour reconvertir l'objet obfusqué vers l'objet typé.
Rien de magique.

---

Je sais mais je disais pas un hack au sens là.

Mais plus le fait de devoir appliquer un visiteur, devoir écrire une classe et la faire hériter de boost::static_visitor<>, et tout le tralala qui va avec quoi.

Plein de petites choses cumulées qui te donnent l'impression que tu n'es pas en train d'écrire quelque chose d'aussi direct qu'une fonction.

---

Et alors quand tu veux écrire un Variant récursif, ça devient pire ! Pour écrire le type, tu te farcis un boost::recursive_wrapper en plus.

Mais bon c'est pourtant une fonctionnalité qui vaut largement le coup!

Salut,

Des fois c'est pratique mais souvent, quand on n'a que des classes avec 3 données membres et 5 méthodes, faut pas exagérer quand même, 'oublier' de tester un pointeur a peu de chance d'arriver...
Compliquer le code (un visiteur sur un Boost.Variant ça complique un poil) pour une garantie de cet ordre bien souvent je ne considère pas vraiment que ça vaut le coup.

Citation:

---

Envoyé par Emmanuel Deloget

Je sais que c'est un peu hors sujet, mais je n'ai pas encore trouvé d'explication suffisament convaincante de cette affaire liée aux pointeurs NULL (comme quoi, avoir à en gérer serait un code smell...). Est-ce que quelqu'un maitrise bien le sujet ?

---

Peut-être parce qu'on peut sans doute toujours remanier pour soit séparer en deux classes (une avec une référence et l'autre sans rien du tout), soit utiliser un Null Object, soit un Composite, etc.. ?

MAT.

Citation:

---

Envoyé par Mat007

Peut-être parce qu'on peut sans doute toujours remanier pour soit séparer en deux classes (une avec une référence et l'autre sans rien du tout), soit utiliser un Null Object, soit un Composite, etc.. ?

MAT.

---

Je ne vois pas de problème pour imaginer des solutions (y compris l'utilisation du pattern Null Object) mais pour être franc, je ne vois pas ce que ça apporte à une implémentation.

J'ai regardé depuis hier si je trouvais quelque chose sur le sujet caché au coeur de l'intraweb, et je n'ai trouvé que des discussions confuses. Je vais regarder dans les bouquins qu'on a u boulot si j'y vois quelque chose.

En gros, la seule chose que j'ai retenu de ce que j'ai lu jusqu'à présent, c'est que l'utilisation d'un pointeur qui peut être NULL entraîne
1) l'implémentation de cas particuliers.
2) de fortes duplications de code.
Le Refactoring de Fowler introduit une courte discussion à propos de ces deux problèmes, dans la partie consacrée au refactoring "introduce null object". Il cite Ron Jeffries:

Citation:

---

We first started using the null object pattern when Rich Garzaniti found that lots of code in the system would check objects for presence before sending a message to the object. We might ask an object for its person, then ask the result whether it was null. If the object was present, we would ask it for its rate. We were doing this in several places, and the resulting duplicate code was getting annoying.

So we implemented a missing-person object that answered a zero rate
(we call our null objects missing objects). Soon missing person knew a
lot of methods, such as rate. Now we have more than 80 null-object
classes.

---

Personnellement, j'ai déjà travaillé sur des projets ou le nombre d'objets pouvant être null était énorme, et même si je conçois que le pattern null object aurait pu être un pattern relativement interessant dans ce cadre, je ne vois toujours pas en quoi le problème est sévère (peut être qu'il ne l'est pas en fait; Fowler et Beck (Refactoring...) ne cite pas de bad smell concernant ce point. Je ne pense pas que ça soit une ommission, car ils introduisent quand même ce refactoring particulier.
Pour continuer avec la description de Jeffries:

Citation:

---

Our most common use of null objects is in the display of information. When we display, for example, a person, the object may or may not have any of perhaps 20 instance variables. If these were allowed to be null, the printing of a person would be very complex. Instead we plug in various null objects, all of which know how to display themselves in an orderly way. This got rid of huge amounts of procedural code.

---

Soit. Je pense que d'autres approches étaient disponibles (comme par exemple encapsuler le code d'affichage de l'information dans plusieurs objets, capable de traiter des pointeurs NULL).

J'ai vaguement regardé dans le Meyer, mais je n'ai pas trouvé grand chose sur le sujet. Il y a encore quelques livres ici que je dois regarder avant d'avoir une vision plus claire du problème, donc si entre temps vous avez des idées sur la question, n'hésitez pas ! :)

Citation:

---

Envoyé par Emmanuel Deloget

(...) je ne vois toujours pas en quoi le problème est sévère (...)

---

Si en effet un accesseur renvoie un pointeur, qui donc peut être nul, ça veut dire que tous les utilisateurs vont devoir tester le pointeur avant de l'utiliser, d'où duplication de code et risque tout de suite beaucoup plus élevé d'oublier de tester (c'est exactement ce que décrit Jeffries).

En fait je viens de réaliser (je n'utilise jamais d'accesseurs) que le problème ne se pose pas tellement lorsqu'un pointeur est encapsulé et reste un détail d'implémentation, mais plus à partir du moment où il est se promène à l'extérieur.
Du coup le fait de devoir beaucoup tester des pointeurs révélerait des problèmes d'encapsulation, ou de sur-utilisation d'accesseurs ?

MAT.

Dans "Refactoring to Patterns" le problème est listé dans les différentes formes que peut prendre le code smell "Conditional Complexity" :

Citation:

---

Envoyé par Refactoring to Patterns

Dealing with null cases often leads to the creation of conditional logic. If the same null conditional logic is duplicated throughout your system, you can clean it up by using Introduce Null Object.

---

Et globalement "Conditional Complexity" est introduit par :

Citation:

---

Envoyé par Refactoring to Patterns

Conditional logic is innocent in its infancy, when it is simple to understand and contained within a few lines of code. Unfortunately, it rarely ages well. For example, you implement several new features ans suddenly you conditional logic becomes complicated and expansive.

---

Il y a un peu plus de contenu dans la description du remaniement "Introduce Null Object" mais globalement ça tourne toujours autour de la même chose...

MAT.

Citation:

---

Envoyé par Mat007

Si en effet un accesseur renvoie un pointeur, qui donc peut être nul, ça veut dire que tous les utilisateurs vont devoir tester le pointeur avant de l'utiliser, d'où duplication de code et risque tout de suite beaucoup plus élevé d'oublier de tester (c'est exactement ce que décrit Jeffries).

---

Grosso modo si on a un objet qui implémente null object, on peut remplacer

Code:

---

1 2 3

objet <- assignation si (objet != NULL) // faire qqc.

---

par :

Code:

---

1 2	objet <- assignation // faire qqc.

---

Une des implications est, qu'à chaque fois, il faudra tester le comportement du code dans le cas "null" et le cas "non null". (Bien sûr, on peut aussi "oublier" de faire le test dans le code et de tester l'oubli...)

Implémenter un nul object dans ce cas, permet de réduire les "cas" possibles... et donc la complexité à un coût plus que raisonnable.

Citation:

---

En fait je viens de réaliser (je n'utilise jamais d'accesseurs) que le problème ne se pose pas tellement lorsqu'un pointeur est encapsulé et reste un détail d'implémentation, mais plus à partir du moment où il est se promène à l'extérieur.
Du coup le fait de devoir beaucoup tester des pointeurs révélerait des problèmes d'encapsulation, ou de sur-utilisation d'accesseurs ?
MAT.

---

Je pencherais plutôt pour une question d'interface.
La classe X définit l'accesseur A qui retourne

• un objet ou nul
• un objet (qui pourra être un null object).

Le client ne pourra peut être pas utiliser le null object comme un object normal dans tous les cas (quoique) mais on essaie bien de limiter les variations dans le code client pour traiter les différents cas.
- W

Citation:

---

Mais plus le fait de devoir appliquer un visiteur, devoir écrire une classe et la faire hériter de boost::static_visitor<>, et tout le tralala qui va avec quoi.

---

Hériter de static_visitor ça sert juste à définir le typedef result_type.
En fait, le problème c'est qu'il faut faire des fonctions. Avec un DSEL pour expression lambda, ça s'écrit plus concisement.

Et les histoires de faux objet vide, ça c'est vraiment un hack.

Citation:

---

Envoyé par HanLee

boost::optional<T>, j'aime pas trop, la valeur est ajoutée est pas énorme, dans le sens où le typage ne te force pas à vérifier si l'objet est nul ou non.

Alors qu'à l'inverse boost::variant<T, null_type> ou le type Option de ML t'oblige à vérifier si l'objet est valide.

---

:koi:
si je comprend bien,boost::optional<T> c'est grosso modo comme tester un pointeur.
boost::variant<T, null_type>, faut tester. ou est la différence??

En tout cas, je pense comprendre mieux le problème que vous pose d'avoir un pointeur NULL, si j'ai bien compris, il faut mieux avoir un objet qui ne fait rien et correspond au null, que d'avoir ce pointeur où l'on peut oublier un teste. C'est bien cela?

Citation:

---

En tout cas, je pense comprendre mieux le problème que vous pose d'avoir un pointeur NULL, on si j'ai bien compris, il faut mieux avoir un objet qui ne fait rien et correspond au null, que d'avoir ce pointeur où l'on peut oublier un teste. C'est bien cela?

---

Oui! Plus de tests if ( x!=0 ) dans le code et plus besoin de tester que le code n'a pas oublié de faire le test.

- W

Citation:

---

Envoyé par Mongaulois

boost::variant<T, null_type>, faut tester. ou est la différence??

---

Avec boost::variant, la différence c'est que tu ne peux pas oublier de tester, dans les conditions normales d'utilisation.

Si t'oublies de traiter le cas null_type, le compilateur t'envoie chier tout simplement.

------

Evidemment, ça ne marche que si tu ne contournes pas le typage, avec les pointeurs par exemple.

Supposons que ça te fasse chier de faire un visiteur, parce que tu sais que l'objet n'est pas nul. Tu vas te faire une fonction get() qui te retourne une référence vers l'objet variant.

Tu dois faire 2 fonctions membres, un qui prend en paramètre le type null_type, et l'autre de type T.
Pourquoi ? Sinon ça compile pas.

Pour traiter le type T, c'est évident, tu retournes le paramètre d'entrée.
Et quand tu traites le type null ?
Bah t'as pas d'autre choix que lancer une exception, si tu veux pas contourner le typage.

Et au final, on a rien gagné, autant écrire la fonction intéressante dans le visiteur, non ?

Si dans le cas nul tu lances une exception ou que tu génères une erreur, c'est que ton état nul n'a pas de raison d'être...

Citation:

---

Envoyé par loufoque

Si dans le cas nul tu lances une exception ou que tu génères une erreur, c'est que ton l'état nul n'a pas de raison d'être...

---

Et c'est ce qui rend la situation encore plus absurde avec ce get().