Discussion :

[camboui]

Je viens de faire un constat contrariant.

Code :

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

1
2
3
#define N sizeof(long)
#if N == 8
...

Code :

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

1
2
3
#define N 4
#if N == 8
...

Le premier code est refusé, le second accepté
Pourquoi qu'il aime pas les sizeof() ?

[white_tentacle]

Parce que sizeof n'est pas géré par le préprocesseur, mais par le compilateur. Et le préprocesseur refuse de comparer des chaînes et des entiers (je ne suis même pas sûr qu'il sache comparer des chaînes, j'ai souvenir que non).

[camboui]

Oui, ça se tient. Logique quelque part.
Mais bon, ce ne serait pas du luxe si le preprocesseur pouvait évaluer les sizeof().

Merci.

[3DArchi]

Mais bon, ce ne serait pas du luxe si le preprocesseur pouvait évaluer les sizeof().

La taille des types est définie par le compilateur. Donc le preprocesseur n'en a aucune idée en fait.

[koala01]

Salut,

Il faut aussi comprendre dans quel ordre tout s'effectue, lorsque tu lance une compilation, entre le code source que tu as écrit et le binaire exécutable que tu obtiens...

Pour faire simple (et donc, de manière pas tout à fait juste), on peut dire qu'il y a cinq étapes distinctes:

1. Les commentaires sont supprimé du code
2. Le préprocesseur passe le premier, et gère ses propres directives (#ifdef, #define, inlcude, ...)
3. Le compilateur converti ce qui reste en code assembleur
4. L'assembleur génère les instructions processeur (binaire objet)
5. L'éditeur de liens relie les fichiers binaires objets de manière à en faire un fichier unique cohérent

Bon, s'il faut être honnête, les compilateurs actuels ne sont plus obligé de passer par une étape en code assembleur, mais ils sont toujours capables de fournir un tel code , et l'éditeur de liens n'intervient que pour les liens internes d'un projet, à condition que ce ne soit pas pour faire une bibliothèque statique...

Par contre, les premiers compilateurs suivaient exactement ce genre de séquence

Et le fait est que l'opérateur sizeof est pris en compte... au moment de créer le code assembleur (lors de l'étape 3, en sommes)...

C'est à dire, bien après que le préprocesseur soit passé par là

Par contre, l'opérateur sizeof est une constante de compilation, ce qui fait que la valeur obtenue grace à lui peut parfaitement être interprétée par le compilateur au moment de la compilation, et non au moment de l'exécution...

Lorsque l'on sait que l'opérateur ternaire ? (qui peut être utilisé pour créer un test sous la forme de <expression constante> ? <faire si Vrai> : <faire si faux> ) peut, lui aussi, être interprété au moment de la compilation, il est tout à fait possible d'envisager de l'utiliser (les utiliser) lorsque l'on travaille avec les templates:

Code :

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

1
2
3
4
5
template <typename T, typename U>
struct unTestQuelconque
{
    enum {value = (sizeof(T)<sizeof(U) ) ? -1 : 1} ;
};

fera que la valeur obtenue par

Code :

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

unTestQuelconque<char, long long>::value

sera évaluée, au moment de la compilation à -1 alors que la valeur obtenue par

Code :

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

unTestQuelconque<long long, char>::value

sera évaluée à 1 (au moment de la compilation, toujours)

[camboui]

Intéressant.
Donc ce genre de code est "incorrect" ?

Code :

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

1
2
3
#ifndef int16
typedef __int16 int16;
#endif

Le typedef n'est défini qu'à la compilation, le preprocesseur ne verra jamais la définition de int16.
D'ordre plus général, les types n'existent pas pour le preprocesseur donc je suppose qu'il est inutile de faire quelque chose comme ceci:

Code :

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

1
2
#ifdef wchar_t
...

C'est alors un peu compliqué de faire du code portable. Il faut connaitre à l'avance quels sont les types reconnus par le compilateur.

Etant donné, que, quand même et malgré tout, preprocesseur et compilateur agissent de concert pour "lire" du code source, je ne verrais pas d'objection à ce qu'une extension soit faite aux preprocesseurs afin qu'ils connaissent les types primitifs du compilateur associé, de même que certaines "fonctions" qui y sont liées (comme sizeof() ou typeid()).
On ne prévoirait pas ça pour la norme C0x++ ?