[C/C++] Support des types enum compacts (et de bool)

On Jun 11, 11:12 pm, "Patrick 'Zener' Brunet"
<use.link.in.signat...@ddress.invalid> wrote:

J'ai des classes qui se veulent "system independent",

Tu entends quoi par « system independant » ? La
représentation interne dépend toujours du système et de
l'architecture sur laquelle il tourne. Et la représentation
externe, c'est à toi de la définir et d'en faire ce que tu veux.

et que je dois rendre très compactes. Donc après les entiers
bien calibrés, je me penche sur les formes compactes du type
enum, et aussi sur le booleen monobyte.

En ce qui concerne la représentation externe, c'est toi qui
choisit.

Donc short enum, char enum et bool.

Très difficile de trouver un bilan de leur support par les compilateurs
"assez" récents.

Il n'y a pas de support des compilateurs pour une représentation
externe quelconque. C'est à toi de jouer, toujours.

Je souhaite au strict minimum la portabilité Windows / Linux.

Écrit correctement, ça va de soi. Les problèmes ne se présentent
que sur des machines où la taille d'un byte n'est pas 8 bits, ou
que la représentation signée n'est pas complément à 2, ou
d'autres choses exotiques du genre.

Dans la logique d'une librairie, je tiens aussi à ne pas
fermer la porte aux outils du fournisseur du système.

Donc après premier essai, MSVC v6.0 supporte bien bool, mais
pas les enums compacts :-(

Encore, ça veut dire quoi, exactement ? Typiquement, un enum a
la taille d'un int, pour des raisons historiques.

**Auriez-vous des liens sur un état des lieux des divers
compilos en service ?

Le compilateur génère ce qu'il génère, généralement en fonction
d'un API système. Le changer cassera trop d'autres choses.

--
James Kanze (GABI Software, from CAI) 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

Bonsoir.

J'ai des classes qui se veulent "system independent", et que je dois rendre
très compactes.
Donc après les entiers bien calibrés, je me penche sur les formes compactes
du type enum, et aussi sur le booleen monobyte.

La taille d'un enum est implmentation-defined dans le standard. La seule
garantie est que cela ne dépasse pas la taille d'un int.

Quand je doit connaitre la taille du type, soit je cast l'enum, soit
j'utilise des constantes.

Dans le premier cas, ça coûte une conversion aux fonctions
d'entrée/sortie, dans le deuxième cas le typage est perdu.

Donc short enum, char enum et bool.

Très difficile de trouver un bilan de leur support par les compilateurs
"assez" récents.

Je souhaite au strict minimum la portabilité Windows / Linux.
Dans la logique d'une librairie, je tiens aussi à ne pas fermer la porte aux
outils du fournisseur du système.

Donc après premier essai, MSVC v6.0 supporte bien bool, mais pas les enums
compacts :-(

MSVC v6.0 date de 98. Ce n'est pas ce que j'appelle un compilateur récent.

**Auriez-vous des liens sur un état des lieux des divers compilos en service
?

Michael

Donc après les entiers bien calibrés, je me penche sur les formes compactes
du type enum, et aussi sur le booleen monobyte.

Donc short enum, char enum et bool.

bool n'a rien de monobyte...

--
Loïc

Donc après les entiers bien calibrés, je me penche sur les formes compactes
du type enum, et aussi sur le booleen monobyte.

Donc short enum, char enum et bool.

bool n'a rien de monobyte...

--
Loïc

Bonsoir.

J'avais oublié... Bon, je traduis:

"Patrick 'Zener' Brunet" <use.link.in.signature@ddress.invalid> a écrit dans
le message news: f4kdfp$la4$1@shakotay.alphanet.ch...

J'ai des classes qui se veulent "system independent", et que je dois
rendre très compactes.

Par "system independent", j'entends qu'elles sont compilables (je n'attends
évidemment aucune compatibilité binaire) sans modification sur tout couple
système + compilo "raisonnable", c'est à dire:
- autorisant des entiers signés ou pas de 8, 16 et 32 bits (à un nommage
près),
- possédant des caractères de 8 bits et le code ASCII,
- et des pointeurs, sans besoin de compatibilité avec les entiers, mais
admettant 0 comme valeur invalide,
- et connaissant le typedef et les modifiers const, mutable et volatile.

Ces classes ne font aucune autre supposition sur le système, et n'utilisent
directement aucune primitive qui le fasse, même de la stdio.
Toutes les primitives de ce type sont reportées dans des modules de portage
totalement substituables.

Mais bon, c'est pas le but de la discussion. Ce qui m'intéresse, c'est la
disponibilité de certains types récents (introduits par C99, et parfois
anticipés par certains compilos).

Donc après les entiers bien calibrés, je me penche sur les formes
compactes du type enum, et aussi sur le booleen monobyte.

Donc short enum, char enum et bool.

Sachant que théoriquement lorsqu'il est supporté, bool est supposé tenir sur
un octet.

Et que par ailleurs pour enum, si le type par défaut est bien supposé être
compatible en taille avec un int, il admet des modifieurs qui sont
normalement char, short, long et long long.

Très difficile de trouver un bilan de leur support par les
compilateurs "assez" récents.

C'est à dire que la librairie doit pouvoir se marier avec toute autre, ainsi
qu'avec le contexte de travail de l'utilisateur.
Je ne compte pas aller dans ce sens jusqu'aux gens qui travaillent sur IBM
TPF ou MS-DOS, mais il y en a encore qui développent pour Win2000 par
exemple...

Mais donc comme ce n'est pas supporté sur plusieurs de ces compilateurs et
que j'en ai besoin, je me suis fait une petite classe template pour gérer
ça.

--
Cordialement.
--
/**************************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************/

On Tue, 12 Jun 2007 19:48:46 +0200, "Patrick 'Zener' Brunet" :

mais il y en a encore qui développent pour Win2000 par
exemple...

Pour W2K ou sous W2K ?
Quelqu'un qui développe sous Windows 2000 peut, il est vrai, avoir des
problèmes pour installer les dernières versions de Visual C++.
Par contre, les compilateurs récents peuvent faire du code compatible
Windows 95, NT4 et 2000 sans problème. Le seul bémol concerne les API
apportées par les Windows plus récents, mais ce problème ne te
concerne pas.

Bonsoir.

"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message news:
fmnt63lvgkqf2i2naun42sd14k5c77uvbi@4ax.com...

On Tue, 12 Jun 2007 19:48:46 +0200, "Patrick 'Zener' Brunet" :

mais il y en a encore qui développent pour Win2000
par exemple...

Pour W2K ou sous W2K ?

Les deux en fait. Il y a quelques années, j'ai dû me battre sur eBay pour
m'offrir le lot à un prix presque abordable, et je n'ai pas trop envie de
refaire ça pour chaque version :-)
D'ailleurs même au niveau des exécutables, une appli écrite (selon les
guidelines) pour Win2000 tourne sur XP, même si c'est sans tous les effets
fluos possible... C'est plutôt le côté fonctionnel qui m'intéresse.

En fait mes classes sont du domaine de la technique, pas de l'IHM. C'est
pourquoi elles doivent pouvoir se combiner avec d'autres librairies.

Quelqu'un qui développe sous Windows 2000 peut, il est vrai, avoir des
problèmes pour installer les dernières versions de Visual C++.

Et il n'a pas forcément envie d'intégrer .NET et tout le reste dans des
projets qui ne le justifient pas.

Par contre, les compilateurs récents peuvent faire du code
compatible Windows 95, NT4 et 2000 sans problème.

C'est la compatibilité des codes sources qui m'intéresse. L'air de rien,
arriver à rendre (par exemple) les MFC possibles mais optionnelles, tout en
redéfinissant l'operateur new (y compris la version à placement), c'était
pas simple.
Et donc là par contre ça me hérisse un peu de devoir "bidouiller proprement"
pour garantir la disponibilité (à un renommage près) d'un enum et d'un bool
sur 8 bits, dans du code system independent :-/
Mais j'ai trouvé comment le faire...

Le seul bémol concerne les API
apportées par les Windows plus récents, mais ce problème
ne te concerne pas.

Dans ce projet, en effet.
J'ai isolé dans des modules de portage les primitives de type temps système,
mutex, section critiques et associés, mémoire, fichiers, etc.
Le reste n'a pas sa place dans un "moteur" et doit aller dans un module
d'interface forcément dédié à une plate-forme.
L'intérêt, c'est de permettre de regrouper dans la partie system independent
80% de la complexité technique.

Merci pour les tuyaux.

--
Cordialement.
--
/**************************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
**************************************************/

Sachant que théoriquement lorsqu'il est supporté, bool est supposé tenir sur
un octet.

Encore une fois, il n'y a aucune supposition de ce genre. Et il y a des
compilateurs où ce n'est pas le cas (en général, dans ce cas, on a
sizeof(bool) == sizeof(int)).

Et que par ailleurs pour enum, si le type par défaut est bien supposé être
compatible en taille avec un int, il admet des modifieurs qui sont
normalement char, short, long et long long.

Il n'y a rien (actuellement du moins) qui permette de spécifier quoi que
ce soit sur le type sous-jacent à une enum en C++ (C99, je ne sais pas).
Et je ne crois pas que ce soit une extension courante des compilateurs.


--
Loïc

On Jun 12, 7:48 pm, "Patrick 'Zener' Brunet"
<use.link.in.signat...@ddress.invalid> wrote:

J'avais oublié... Bon, je traduis:

"Patrick 'Zener' Brunet"
<use.link.in.signat...@ddress.invalid> a écrit dans le
messagenews:
f4kdfp$la__BEGIN_MASK_n#9g02mG7!__...__END_MASK_i?a63jfAD$z__@shakotay.al phanet.ch...

J'ai des classes qui se veulent "system independent", et que
je dois rendre très compactes.

Dans quel but ? Si tu as d'énormes tableaux des telles classes,
tu pourrais considérer des bit-fields ; ils ont été conçus
précisement pour ça.

Par "system independent", j'entends qu'elles sont compilables
(je n'attends évidemment aucune compatibilité binaire) sans
modification sur tout couple système + compilo "raisonnable",

« Raisonable » dépend du contexte où on se place, je crois.
Disons plutôt que tu n'as pas besoin d'une portabilité vers une
architecture « exotique » (parce que ce sont les différences
dans l'architecture qui conditionnent souvent les variations
dans les compilateurs).

c'est à dire:
- autorisant des entiers signés ou pas de 8, 16 et 32 bits (à un nomm age
près),
- possédant des caractères de 8 bits et le code ASCII,
- et des pointeurs, sans besoin de compatibilité avec les entiers, mais
admettant 0 comme valeur invalide,
- et connaissant le typedef et les modifiers const, mutable et volatile.

Ce sont des choses plus ou moins universel. Pour les deux
premiers, évidemment, le compilateur va s'aligner sur
l'architecture et le système ; on ne peut pas s'attendre à des
entiers à 32 bits si le hardware est à 36 bits, et les gros IBM
utilisent toujours de l'EBCDIC en natif (mais au moins à une
époque, le run-time du compilateur traduisait en ASCII pour les
fichiers texte, de façon à ce qu'interne, un programme en C
travaillait en ASCII).

La seule exception à ma connaissance est « volatile » ; ce
mot-clé n'a pas vraiment une sémantique normalisée, et sur les
compilateurs que je connais (Sun CC, g++ et VC++), ne fait rien
d'utile ou d'intéressant ; on pourrait prèsque le considérer
comme un no-op.

Ces classes ne font aucune autre supposition sur le système,
et n'utilisent directement aucune primitive qui le fasse, même
de la stdio. Toutes les primitives de ce type sont reportées
dans des modules de portage totalement substituables.

Mais bon, c'est pas le but de la discussion. Ce qui
m'intéresse, c'est la disponibilité de certains types récents
(introduits par C99, et parfois anticipés par certains
compilos).

Le fichier <stdint.h> ne me semble pas si répandu que ça ; je
l'ai sous Linux, mais pas sous Solaris ni sous Windows.

Donc après les entiers bien calibrés, je me penche sur les
formes compactes du type enum, et aussi sur le booleen
monobyte.

Donc short enum, char enum et bool.

Sachant que théoriquement lorsqu'il est supporté, bool est
supposé tenir sur un octet.

Je ne sais pas d'où tu as ça. La norme ne dit rien sur la taille
d'un bool. Sur une architecture où les accès à un octet sont
aussi vite que ceux à un mot, je m'attendrais bien que la taille
de bool soit 1. Mais sur des architectures où un accès mot est
plus rapide qu'un accès octet, il y a un choix entre vitesse et
espace à faire, et ça ne m'étonnerait pas que beaucoup de
compilateurs choisissent la vitesse.

Et que par ailleurs pour enum, si le type par défaut est bien
supposé être compatible en taille avec un int, il admet des
modifieurs qui sont normalement char, short, long et long
long.

Comment ça ? La norme ne dit rien en ce qui concerne la taille
d'un enum, sauf qu'il soit assez grand pour contenir toutes les
valeurs, et qu'il ne soit pas plus grand qu'un int, sauf s'il le
faut. Sinon, la taille dépend de l'implémentation. Et tu ne peux
le modifier qu'avec un champs à bits, c-à-d :

enum Toto { a, b, c } ;
Toto titi ; // occupe toujours 4 octets avec
// mes compilateurs...
struct Tata
{
Toto titi : 2 ;
// n'occupe que deux bits...
int autreChose : 30 ;
} ;

--
James Kanze (GABI Software, from CAI) 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

In article <1181720884.655308.143240@o11g2000prd.googlegroups.com>,
James Kanze <james.kanze@gmail.com> wrote:

Le fichier <stdint.h> ne me semble pas si répandu que ça ; je
l'ai sous Linux, mais pas sous Solaris ni sous Windows.

Tu es un peu traditionnel et en retard. Ca m'etonnerait beaucoup
que les versions *recentes* des environnements de travail Windows
et Solaris n'aient pas stdint.h.

Les choses evoluent vite. Il y a trois ans, c'etait courant de ne
pas avoir stdint.h. Aujourd'hui, ca denote de serieuses lacunes
de mise-a-jour...