Les types de données peuvent être différent d'un systéme à un autre.
Afin d'assurer la portabilité de mon appli, dois-je définir un fichier
de #define dont l'idée est :
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fabien LE LEZ
On Sun, 10 Jun 2007 00:01:08 +0200, TSalm :
#ifdef __SYSTEME_TYPE__ #define INT int #endif
Utiliser #define est une mauvaise idée dans la quasi-totalité des cas[*]. À remplacer par typedef.
Sinon, l'idée est bonne, à ceci près que tu ne voudras sans doute pas définir un type "INT" mais quelque chose de plus précis, comme "signed_int_32_bits" ou "unsigned_int_64_bits" (avec des noms un peu plus courts, bien sûr).
[*] Imagine que tu aies deux headers :
A.h (que tu as écrit)
#define INT int
B.h (qui vient, par exemple, d'une bibliothèque externe)
class Machin { unsigned short INT; };
Si tu inclus B.h, puis A.h, ça compilera sans problème. Si tu inclus A.h, puis B.h, tu auras une erreur bizarre, dans un header que tu ne connais pas forcément.
On Sun, 10 Jun 2007 00:01:08 +0200, TSalm <tsalm@free.fr>:
#ifdef __SYSTEME_TYPE__
#define INT int
#endif
Utiliser #define est une mauvaise idée dans la quasi-totalité des
cas[*].
À remplacer par typedef.
Sinon, l'idée est bonne, à ceci près que tu ne voudras sans doute pas
définir un type "INT" mais quelque chose de plus précis, comme
"signed_int_32_bits" ou "unsigned_int_64_bits" (avec des noms un peu
plus courts, bien sûr).
[*] Imagine que tu aies deux headers :
A.h (que tu as écrit)
#define INT int
B.h (qui vient, par exemple, d'une bibliothèque externe)
class Machin
{
unsigned short INT;
};
Si tu inclus B.h, puis A.h, ça compilera sans problème.
Si tu inclus A.h, puis B.h, tu auras une erreur bizarre, dans un
header que tu ne connais pas forcément.
Utiliser #define est une mauvaise idée dans la quasi-totalité des cas[*]. À remplacer par typedef.
Sinon, l'idée est bonne, à ceci près que tu ne voudras sans doute pas définir un type "INT" mais quelque chose de plus précis, comme "signed_int_32_bits" ou "unsigned_int_64_bits" (avec des noms un peu plus courts, bien sûr).
[*] Imagine que tu aies deux headers :
A.h (que tu as écrit)
#define INT int
B.h (qui vient, par exemple, d'une bibliothèque externe)
class Machin { unsigned short INT; };
Si tu inclus B.h, puis A.h, ça compilera sans problème. Si tu inclus A.h, puis B.h, tu auras une erreur bizarre, dans un header que tu ne connais pas forcément.
TSalm
[*] Imagine que tu aies deux headers :
A.h (que tu as écrit)
#define INT int
B.h (qui vient, par exemple, d'une bibliothèque externe)
class Machin { unsigned short INT; };
Si tu inclus B.h, puis A.h, ça compilera sans problème. Si tu inclus A.h, puis B.h, tu auras une erreur bizarre, dans un header que tu ne connais pas forcément.
Ne serais-ce ps le contraire ? A.h est le fichier contenant la définition utilsé dans B.h, ce devrait être B.h qui devrait être inclus après (?)
[*] Imagine que tu aies deux headers :
A.h (que tu as écrit)
#define INT int
B.h (qui vient, par exemple, d'une bibliothèque externe)
class Machin
{
unsigned short INT;
};
Si tu inclus B.h, puis A.h, ça compilera sans problème.
Si tu inclus A.h, puis B.h, tu auras une erreur bizarre, dans un
header que tu ne connais pas forcément.
Ne serais-ce ps le contraire ?
A.h est le fichier contenant la définition utilsé dans B.h, ce devrait
être B.h qui devrait être inclus après (?)
B.h (qui vient, par exemple, d'une bibliothèque externe)
class Machin { unsigned short INT; };
Si tu inclus B.h, puis A.h, ça compilera sans problème. Si tu inclus A.h, puis B.h, tu auras une erreur bizarre, dans un header que tu ne connais pas forcément.
Ne serais-ce ps le contraire ? A.h est le fichier contenant la définition utilsé dans B.h, ce devrait être B.h qui devrait être inclus après (?)
Serge Paccalin
Le dimanche 10 juin 2007 à 01:15:18, TSalm a écrit dans fr.comp.lang.c++ :
[*] Imagine que tu aies deux headers :
A.h (que tu as écrit) #define INT int
B.h (qui vient, par exemple, d'une bibliothèque externe) class Machin { unsigned short INT; };
Si tu inclus B.h, puis A.h, ça compilera sans problème. Si tu inclus A.h, puis B.h, tu auras une erreur bizarre, dans un header que tu ne connais pas forcément.
Ne serais-ce ps le contraire ? A.h est le fichier contenant la définition utilsé dans B.h, ce devrait être B.h qui devrait être inclus après (?)
Eh non, justement. B.h n'utilise PAS la définition de A.h, au contraire, cette définition contrarie ce que veut faire B.h (définir une donnée-membre de Machin qui s'appellerait INT).
-- ___________ _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Pour bien répondre avec Google, ne pas cliquer -'(__) « Répondre », mais « Afficher les options », _/___(_) puis cliquer « Répondre » (parmi les options).
Le dimanche 10 juin 2007 à 01:15:18, TSalm a écrit dans
fr.comp.lang.c++ :
[*] Imagine que tu aies deux headers :
A.h (que tu as écrit)
#define INT int
B.h (qui vient, par exemple, d'une bibliothèque externe)
class Machin
{
unsigned short INT;
};
Si tu inclus B.h, puis A.h, ça compilera sans problème.
Si tu inclus A.h, puis B.h, tu auras une erreur bizarre, dans un
header que tu ne connais pas forcément.
Ne serais-ce ps le contraire ?
A.h est le fichier contenant la définition utilsé dans B.h, ce devrait
être B.h qui devrait être inclus après (?)
Eh non, justement. B.h n'utilise PAS la définition de A.h, au contraire,
cette définition contrarie ce que veut faire B.h (définir une
donnée-membre de Machin qui s'appellerait INT).
--
___________
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Pour bien répondre avec Google, ne pas cliquer
-'(__) « Répondre », mais « Afficher les options »,
_/___(_) puis cliquer « Répondre » (parmi les options).
Le dimanche 10 juin 2007 à 01:15:18, TSalm a écrit dans fr.comp.lang.c++ :
[*] Imagine que tu aies deux headers :
A.h (que tu as écrit) #define INT int
B.h (qui vient, par exemple, d'une bibliothèque externe) class Machin { unsigned short INT; };
Si tu inclus B.h, puis A.h, ça compilera sans problème. Si tu inclus A.h, puis B.h, tu auras une erreur bizarre, dans un header que tu ne connais pas forcément.
Ne serais-ce ps le contraire ? A.h est le fichier contenant la définition utilsé dans B.h, ce devrait être B.h qui devrait être inclus après (?)
Eh non, justement. B.h n'utilise PAS la définition de A.h, au contraire, cette définition contrarie ce que veut faire B.h (définir une donnée-membre de Machin qui s'appellerait INT).
-- ___________ _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Pour bien répondre avec Google, ne pas cliquer -'(__) « Répondre », mais « Afficher les options », _/___(_) puis cliquer « Répondre » (parmi les options).
Michael DOUBEZ
Bonjour,
Les types de données peuvent être différent d'un systéme à un autre. Afin d'assurer la portabilité de mon appli, dois-je définir un fichier de #define dont l'idée est :
#ifdef __SYSTEME_TYPE__ #define INT int #endif
ou C++ propose t-il une solution ?
C++ non mais les compilateurs C99 proposent stdint.h qui offre des garanties plus contraignantes sur les types (sint32_t, uint32_t ...).
Ce header est proposé pour C0x, je n'en connais pas le statut. Mais il est en général présent avec les compilateurs C++ saufs pour les plus anciens.
Michael
Bonjour,
Les types de données peuvent être différent d'un systéme à un autre.
Afin d'assurer la portabilité de mon appli, dois-je définir un fichier
de #define dont l'idée est :
#ifdef __SYSTEME_TYPE__
#define INT int
#endif
ou C++ propose t-il une solution ?
C++ non mais les compilateurs C99 proposent stdint.h qui offre des
garanties plus contraignantes sur les types (sint32_t, uint32_t ...).
Ce header est proposé pour C0x, je n'en connais pas le statut. Mais il
est en général présent avec les compilateurs C++ saufs pour les plus
anciens.
Les types de données peuvent être différent d'un systéme à un autre. Afin d'assurer la portabilité de mon appli, dois-je définir un fichier de #define dont l'idée est :
#ifdef __SYSTEME_TYPE__ #define INT int #endif
ou C++ propose t-il une solution ?
C++ non mais les compilateurs C99 proposent stdint.h qui offre des garanties plus contraignantes sur les types (sint32_t, uint32_t ...).
Ce header est proposé pour C0x, je n'en connais pas le statut. Mais il est en général présent avec les compilateurs C++ saufs pour les plus anciens.
Michael
Cyrille
Ce header est proposé pour C0x, je n'en connais pas le statut. Mais il est en général présent avec les compilateurs C++ saufs pour les plus anciens.
Et la bibliothèque Boost contient un header équivalent proposant les mêmes types.
-- Cyrille
Ce header est proposé pour C0x, je n'en connais pas le statut. Mais il
est en général présent avec les compilateurs C++ saufs pour les plus
anciens.
Et la bibliothèque Boost contient un header équivalent proposant les
mêmes types.
Ce header est proposé pour C0x, je n'en connais pas le statut. Mais il est en général présent avec les compilateurs C++ saufs pour les plus anciens.
Et la bibliothèque Boost contient un header équivalent proposant les mêmes types.
-- Cyrille
James Kanze
On Jun 11, 9:09 am, Michael DOUBEZ wrote:
Les types de données peuvent être différent d'un systéme à un autre. Afin d'assurer la portabilité de mon appli, dois-je définir un fich ier de #define dont l'idée est :
#ifdef __SYSTEME_TYPE__ #define INT int #endif
ou C++ propose t-il une solution ?
C++ non mais les compilateurs C99 proposent stdint.h qui offre des garanties plus contraignantes sur les types (sint32_t, uint32_t ...).
Ce header est proposé pour C0x, je n'en connais pas le statut. Mais il est en général présent avec les compilateurs C++ saufs pour les plus anciens.
C'est à peu près certain de faire partie de la prochaine version de la norme. Sous le nom <cstdint>, évidemment:-).
-- James Kanze (Gabi Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Jun 11, 9:09 am, Michael DOUBEZ <michael.dou...@free.fr> wrote:
Les types de données peuvent être différent d'un systéme à un autre.
Afin d'assurer la portabilité de mon appli, dois-je définir un fich ier
de #define dont l'idée est :
#ifdef __SYSTEME_TYPE__
#define INT int
#endif
ou C++ propose t-il une solution ?
C++ non mais les compilateurs C99 proposent stdint.h qui offre des
garanties plus contraignantes sur les types (sint32_t, uint32_t ...).
Ce header est proposé pour C0x, je n'en connais pas le statut. Mais il
est en général présent avec les compilateurs C++ saufs pour les plus
anciens.
C'est à peu près certain de faire partie de la prochaine
version de la norme. Sous le nom <cstdint>, évidemment:-).
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Les types de données peuvent être différent d'un systéme à un autre. Afin d'assurer la portabilité de mon appli, dois-je définir un fich ier de #define dont l'idée est :
#ifdef __SYSTEME_TYPE__ #define INT int #endif
ou C++ propose t-il une solution ?
C++ non mais les compilateurs C99 proposent stdint.h qui offre des garanties plus contraignantes sur les types (sint32_t, uint32_t ...).
Ce header est proposé pour C0x, je n'en connais pas le statut. Mais il est en général présent avec les compilateurs C++ saufs pour les plus anciens.
C'est à peu près certain de faire partie de la prochaine version de la norme. Sous le nom <cstdint>, évidemment:-).
-- James Kanze (Gabi Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
TSalm
Eh non, justement. B.h n'utilise PAS la définition de A.h, au contraire, cette définition contrarie ce que veut faire B.h (définir une donnée-membre de Machin qui s'appellerait INT).
oui, évidemment. Merci pour ce petit conseil TSalm
Eh non, justement. B.h n'utilise PAS la définition de A.h, au contraire,
cette définition contrarie ce que veut faire B.h (définir une
donnée-membre de Machin qui s'appellerait INT).
oui, évidemment.
Merci pour ce petit conseil
TSalm
Eh non, justement. B.h n'utilise PAS la définition de A.h, au contraire, cette définition contrarie ce que veut faire B.h (définir une donnée-membre de Machin qui s'appellerait INT).
oui, évidemment. Merci pour ce petit conseil TSalm
TSalm
merci à tous,
je vais donc plutôt voir du côté de bibliothéques déjà écrite.
merci à tous,
je vais donc plutôt voir du côté de bibliothéques déjà écrite.
