From 6239615047445450108 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,7538bd92d6a9557a X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1995-01-18 01:15:56 PST Newsgroups: comp.std.c++ From: kevlin@wslint.demon.co.uk (Kevlin Henney) Path: nntp.gmd.de!Germany.EU.net!howland.reston.ans.net!news.sprintlink.net!redstone.interpath.net!ddsw1!godot.cc.duq.edu!newsfeed.pitt.edu!uunet!pipex!peernews.demon.co.uk!wslint.demon.co.uk!kevlin Subject: Re: short enum, bool References: <3f9n22$es3@engnews2.Eng.Sun.COM> <3fa97p$b85@ixnews3.ix.netcom.com> <790274478snz@wslint.demon.co.uk> Organization: Westinghouse Systems Ltd. Reply-To: Kevlin@wslint.demon.co.uk X-Newsreader: Demon Internet Simple News v1.27 Lines: 96 X-Posting-Host: wslint.demon.co.uk Date: Wed, 18 Jan 1995 09:15:56 +0000 Message-ID: <790420556snz@wslint.demon.co.uk> Sender: usenet@demon.co.uk In article scotty@netcom.com "J Scott Peter" writes: >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 difference between bool and enum, and the other integer types, relates to range and not just bytesize: bool takes one of two values, enums take the the next power of 2 above the highest constant member, whereas the maximum value of an integer will change with the byte size. If you change the bytesize of a bool or enum, does the range increase? Or does the bytesize just change? If it is the former, then that is nonsensical. If it is the latter, then this is not the same as for ints, and so the analogy / prior art you are referring to does not exist. Also, the compiler does not necessarily choose the most efficient type for an int - this is an efficiency myth. >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.) These aren't just different sizes, they are different types. >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. If you were writing this code from scratch, then the answer would be obvious. However, you are trying to interface to an existing API. The latter leaves a bad taste, and the former should be rejigged to use consts or an anonymous enum. Leave short in there as it's the OS API. Put your abstraction in the next level up and use the native structure, I presume the API provides, rather than providing your own. Wrap it up. >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!*. Use the existing structures, then :-) +---------------------------+-------------------------------------------+ | Kevlin A P Henney | Human vs Machine Intelligence: | | kevlin@wslint.demon.co.uk | Humans can wreck a nice beach more easily | | Westinghouse Systems Ltd | | +---------------------------+-------------------------------------------+