From -540975082586212093
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,7538bd92d6a9557a
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1995-01-20 03:53:28 PST
Newsgroups: comp.std.c++
From: kevlin@wslint.demon.co.uk (Kevlin Henney)
Path: pad-thai.cam.ov.com!bloom-beacon.mit.edu!gatech!howland.reston.ans.net!news.sprintlink.net!pipex!peernews.demon.co.uk!wslint.demon.co.uk!kevlin
Subject: Re: short enum, bool
References: <scottyD2DFML.MDt@netcom.com>
Organization: Westinghouse Systems Ltd.
Reply-To: Kevlin@wslint.demon.co.uk
X-Newsreader: Demon Internet Simple News v1.27
Lines: 91
X-Posting-Host: wslint.demon.co.uk
Date: Fri, 20 Jan 1995 10:10:22 +0000
Message-ID: <790596622snz@wslint.demon.co.uk>
Sender: usenet@demon.co.uk

In article <scottyD2DFML.MDt@netcom.com>
           scotty@netcom.com "J Scott Peter" writes:

>Forgive me if this has been addressed already.

Forgiven, but yes it has been.

>In the same way that one can specify an int or unsigned int as long or short,
>one should be able to specify other integral types (i.e.  enums and bools) as
>long, short, or char sized.

You're not just specifying the byte size, you are specifying the range.
They are different types with different limits. A bool can only hold one
of two values, and an enum also has a fixed range. Live with the types
as they come.

>This is desirable in order to:
>    Save space.  Enums are a great convenience, and the new bool type is as
>    well.  But if one wants to have a char-or short-sized variable, to save
>    space in a structure or array, one has to declare a char or short.  One
>    loses the semantics of the enum or bool.

This is of no use for general programming.

>    Conform to operating-system structures.  Many structures used by OS
>    system calls contain char-or short-sized fields which have the semantics
>    of a bool or enum.  It would be better to declare them as such in the
>    structure definition, but this is currently impossible.

At this level, it would be preferable to use the OS primitives provided
and wrap them up at the next level. Review the program's design instead
of changing the language.

>It is *not* sufficient to have a compiler-flag for `short' enums or bools.
>This would not allow one to choose when and where to make enums/bools shorter
>than int, to conform to a particular structure.
>
>Suggested behavior:
>    The following constructs are syntactically equivalent.  They serve
>    to modify the semantics of a byte/short/int/long variable:
>
>        signed
>        unsigned
>        bool
>        enum <tag>
>
>    In order to allow byte-sized bools/enums, a new keyword `byte', with the
>    same syntactical behavior as `short' and `long' should be created.
>
>    This is better than using `char' to declare byte-sized integers, because
>    you don't have to change the syntactical behavior of `char'.
>    Furthermore, you could then distinguish between ASCII characters and
>    byte-sized integers.  A byte variable would promote to an int, and
>    overload like an int.  A byte enum <tag> variable would overload like
>    enum <tag>, etc.  A char variable would still overload like a char.

A byte is defined in the C standard as char. A char is an integral type,
so you would gain nothing. If you want a small integer use a signed char,
and if you want a small unsigned integer use an unsigned char. This is
existing practice and no new types are required.

>    (Without creating a new keyword, one could make `short short' do the same
>    thing.  Any reasonable programmer would then `#define byte short short').

Oh yeah? ;-)

>Example usages:
>    enum greeting { Yo, Mama, Eats, My, Shorts };
>
>    greeting a;        // int-sized
>    short greeting b;  // short-sized
>    byte greeting d;   // byte-sized
>    greeting byte e;   // same thing
>
>    byte bool f;
>    bool byte g;
>
>    typedef byte greeting grtng;
>    grtng h;                // byte-sized

What did you just gain with this? AFAICS, nothing :-(

Hey, isn't it about time somebody asked about enum inheritance? (HHOK)
Nobody's suggested adding that to the language for at least a couple of months
<grin>

+---------------------------+------------------------------------+
| Kevlin A P Henney         | Money confers neither intelligence |
| kevlin@wslint.demon.co.uk | nor wisdom on those who spend it   |
| Westinghouse Systems Ltd  |                                    |
+---------------------------+------------------------------------+