From -3033729194851451420 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,7538bd92d6a9557a X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1995-01-16 15:34:49 PST Newsgroups: comp.std.c++ Path: nntp.gmd.de!Germany.EU.net!howland.reston.ans.net!ix.netcom.com!netcom.com!scotty From: scotty@netcom.com (J Scott Peter) Subject: Re: short enum, bool Message-ID: Organization: NETCOM On-line Communication Services (408 261-4700 guest) X-Newsreader: TIN [version 1.2 PL1] References: <3f9n22$es3@engnews2.Eng.Sun.COM> <3fa97p$b85@ixnews3.ix.netcom.com> <790274478snz@wslint.demon.co.uk> Date: Mon, 16 Jan 1995 23:34:49 GMT Lines: 104 Kevlin Henney (kevlin@wslint.demon.co.uk) says: > [stuff about choosing efficient sizes for enums deleted] > >That behavior takes just a little too much power out of the programmers hands. > >if an "efficient" size isn't the same size as an 'int' (I apologize for not > >being quite up to date) I think that this would also lead to unexpected > >behavior. > Given that the programmer didn't have that 'power' in the first place, in > either C or C++, nothing is lost I'm afraid. I am the original poster who requested the `short bool' and `short enum' feature. I think that many of the replies that stated that the feature would not add anything, is not needed, and would result in more confusion than clarity, are really obfuscating the issue. They imply that I want to do something special, that is outside the area of normal C/C++, or that I want more portability than is intrinsically possible, or something like that. Let me simply restate the issue: I just want to do with bools and enums what I can already do with ints. Everything the replies have said of bools and enums applies also to ints: By default, the compiler chooses the most efficent storage size for an int. If you want a different size, you don't really *need* short/long/byte keywords. You could do it with bitfields, you could do it with a specialised array template, blah blah blah. The fact is, though, that we have these very useful keywords `long' and `short', which modify the size of `int' (and `char', which declares a different size). True, short and long don't guarantee a particular byte size on every machine. But, using them, one can write interface code to just about any structure used by a particular operating system on a particular machine. Furthermore, one can create space-saving arrays without C++ gymnastics. (And one could even guarantee an absolute byte size on practically any machine by using machine-specific defines; e.g. `typedef int4 long' or `typedef int4 int', depending on the machine.) I just want the same size-specifying ability to extend to the other integral types. > Only problems need solutions, and since there is no problem here no change > to the language is needed ;-) Yeah, so since we don't *need* short or long ints either, wouldn't the language have been better of without them? In fact, there *is* a need I have in particular for them: I'm trying to write C++ wrapper code for the Amiga OS calls. Like most windowing operating systems, the Amiga's is very structure-dependent, with dozens of structures around which the OS calls revolve. It cries out to have a class-oriented interface, with simple inline member functions, laid on top of it. Anyway, my problem has nothing to do with OOP, but with just trying to simplify the interface in general. Tell me, which is more elegant: #define HEAVE_NORMAL 0 #define HEAVE_CHUNKY 1 #define HEAVE_PROJECTILE 2 ... struct Excretion { ... short heave_type; // One of the HEAVE_ values }; Or this: enum Heave {HEAVE_NORMAL, HEAVE_CHUNKY, HEAVE_PROJECTILE}; struct Excretion { ... short Heave heave_type; } The answer is obvious, except I can't do it that way, because it's short. These fields are all over the place. Again, for those not getting the point: It has nothing to do with whether a short-sized variable is more efficient than an int-sized variable. *I'm trying to interface to already existing structures!*. Sorry, bitfields are not good enough. First, they're just ugly. They're problematic in general: declaring a field 16 bits might not result in the same alignment as declaring a field `short'. And as for bools, gcc won't even let me make a bitfield bool of more than 8 bits. Furthermore, in this case, a `short' int variable already existed in C code for the API. In order to change it to a bitfield, I have to know how many bits a short is on this machine, and the alignment behavior it imposes on surrounding fields. Otherwise, I can't make it an enum, and I lose convenience. Short and long exist in C because they're useful. Their usefulness applies to bools and enums exactly as much as they do to ints, and the language should reflect that. And as for `byte': I need that for the same reason: some fields in existing Amiga structures are byte-sized bools and enums, they just aren't declared that way. If I could declare a `char enum', that would be fine too. But it would require changing the way `char' parses (you'd have to allow `char int'), and then you'd have a confusion regarding overloading: does a `char enum' overload as a char or as an enum? That's why a new `byte' keyword would be better: like short and long, it would specify only size, not underlying type behavior. -- J Scott Peter XXXIII // Wrong thinking is punishable. scotty@netcom.com // Right thinking is as quickly rewarded. Los Angeles // You will find it an effective combination.