Discussion :

[3DArchi]

Me v'là avoir perdu 5 bonnes minutes à cause d'une bête erreur. Quelqu'un pourrait m'expliquer pourquoi ni gcc ni VisualExpress ne râle avec une ligne comme ça:

Code :

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

1
2
void *p;
p = false;

Oui, oui. Et après cela, p vaut bien NULL!

[ram-0000]

Visual Studio 2005 ne râle pas non plus (avec warning level 4)

Peut être parce que false vaut 0 et que c'est autorisé de mettre 0 dans un pointeur.

Par contre, le code suivant provoque un warning "impossible de convertir de '' en 'void *'"

Code :

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

1
2
3
4
5
6
7
8
enum { val_0, val_1 };
 
int main(void)
{
   void *p;
   p = val_0;
   return 0;
}

[koala01]

Salut,

Simplement, parce que, la seule chose dont on soit sur, c'est que false vaut 0, alors que true vaut... tout le reste (même si la norme refuse que l'on puisse envisager d'incrémenter true ).

A coté de cela, il se fait que NULL correspond à une adresse invalide, et, elle aussi, vaut 0 (0x00000000)...

En effet, la plupart des implémentation de NULL sont de l'ordre de

Code :

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

#define NULL ((void*) 0)

La preuve en est que tu peux tester ton pointeur directement sous la forme de
if(ptr) pour t'assurer qu'il a été initialisé ou de if(!ptr) pour t'assurer qu'il n'existe pas

Dés lors, que tu utilise false, 0 ou NULL pour t'assurer qu'un pointeur est invalide reviendra toujours au même

Il est à noter que la nouvelle norme va introduire le terme null_ptr, qui sera plus explicite quant à la représentation, mais qui risque quand meme de n'etre, à l'implémentation que quelque chose comme...

Code :

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

#define null_ptr NULL

(à confirmer )

[ram-0000]

Oui je suis tout à fait d'accord mais alors pourquoi mon exemple avec une enum et val_0 (qui vaut 0, j'en suis sûr, j'ai regardé au debugger) provoque t'il un warning à la compilation.

Cela veut t'il dire que le type boolean n'est pas un type mais un espece de nombre puisque'on peut faire "void *p = false" mais pas "void *p = val_0"

[koala01]

Le type booléen est malheureusement lui aussi un #define de l'ordre de

Code :

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

1
2
#define false 0
#define true !false

(ou quelque chose dans le genre)

Alors que l'énumération correspond à un TAD, au même titre qu'une structure, une union ou une classe.

Il peut donc y avoir une vérification de type sur une énumération qu'il ne peut pas y avoir avec un booléen

C'est la raison pour laquelle il est généralement recommandé d'utiliser les énumérations en lieu et place d'une série de #define "concurrents": Avec les #define, il ne peut y avoir aucune vérification quant à cohérence de la valeur utilisée, alors que, dans le cas des énumérations, les valeur sont regroupées... au sein du type dans lequel elles sont énumérées, ce qui permet au compilateur:

• de vérifier si la valeur est du type attendu
• de vérifier, dans le cas d'un test à choix multiple ("switch... case" ) de s'assurer que toutes les valeurs seront envisagées

[kinji1]

Les enum et les int ne sont pas convertibles implicitement en void*, ni les bool d'ailleurs (en tout cas gcc sort des erreurs), il faut croire que false (le littéral) lui a le droit d'être convertit en void*, true ne le peut pas.

Je sais pas si le coup du false est défini dans la norme ou si c'est juste les compilos qui sont permissifs.

[koala01]

En fait, ce que la norme dit, c'est:

• les litéraux booléens sont les mots clé true et false
• ces litéraux ont le type bool
• Ce ne sont pas des lvalue
• ils participe au processus de promotion des types entiers
• les conversions en booléen sont implicites, et interviennent au même niveau que les conversion numériques (promotions d'entier ou de réels, conversion d'entier, de réels en entiers, de pointeurs et de pointeurs sur membres)
• une rvalue arithmétique, une énumération, un pointeur et un pointeur sur membre peuvent être convertie en rvalue de type bool. Une valeur nulle, un pointeur à valeur nulle, ou un pointeur sur membre à valeur nulle sera converti à false; tout autre valeur sera convertie à true
• une rvalue de type bool peut etre convertie en entier, false devenant 0 et true devenant 1
• surement encore d'autres choses intéressantes...

Ce qu'il ressort de tout cela, c'est que, au final tout peut être converti en booléen selon le principe 0 ==> false !0==>true et un booleen peut être converti en n'importe quoi selon le principe false ==>0 true ==>1

NULL étant le transtypage "barbare" de 0 en un pointeur de type void, mais un pointeur n'étant jamais qu'un entier (soit unsigned int soit unsigned long), et les entiers étant implicitement convertibles en booléen, mais un booléen intervenant dans l'ordre des promotions d'entiers (bool->char->short->int->long), l'initialisation d'un pointeur à false correspond exactement à l'initialisation à NULL...

Comme indiqué, du fait qu'une énumération représente un type abstrait de donnée, le C++ est capable de vérifier si le type correspond à ce qui est attendu, ce qui justifie que, de son coté, l'utilisation d'une valeur énumérée valant 0 ne pourra être envisagée que si elle est transtypée en pointeur du type correspondant

[Florian Goo]

Il est à noter que la nouvelle norme va introduire le terme null_ptr, qui sera plus explicite quant à la représentation, mais qui risque quand meme de n'etre, à l'implémentation que quelque chose comme...

Code :

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

#define null_ptr NULL

(à confirmer )

Euh, non, quand même pas… sinon quel serait l'intérêt de ce nouveau mot-clé ?!
http://www.open-std.org/jtc1/sc22/wg...2007/n2431.pdf
Il s'agit de nullptr, et non null_ptr

[Alp]

Je me suis embêté à faire un billet dessus
http://blog.developpez.com/alp?title..._le_pointeur_n

Bonne lecture

[Médinoc]

D'après ton article, nullptr est une valeur d'un nouveau type std::nullptr_t.
Ça me rappelle beaucoup la manip artisanale que j'avais faite...