[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?)
From: |
Pascal J . Bourguignon |
Subject: |
Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?) |
Date: |
Tue, 3 Feb 2004 06:18:32 +0100 |
Helge Hess writes:
> On 02.02.2004, at 20:47, Nicola Pero wrote:
> >> I would again like to point out that if the intention was to limit
> >> BOOL
> >> to YES and NO, it would have been defined as
> >> typedef enum { YES, NO } BOOL;
> >
> > Wouldn't this have been a waste a space just to just store a YES/NO ?
>
> Well, isn't that you who is suggesting that a "true boolean" is worth
> major restrictions? ;-)
>
> Your point is pretty mood because:
> a) BOOL is *NOT* specified to be char and indeed is not mapped to char
> on some platforms
> Is int more wasteful than that:
> @interface MyFunkyObject
> {
> BOOL a;
> BOOL b;
> }
> I guess not, because a and b are probably aligned to 32 bits
> boundaries.
You lucky guy! you must be working on a Cray. That's the only
architecture I know where bytes are aligned as integers. Everywhere
else, bytes are ligned on byte boundaries. That's the point of having
bytes.
> Is
> - (void)doIt:(BOOL)_a
> more wasteful than int? I also guess not, because the register _a is
> being passed in is available in any case and probably not going to be
> shared by multiple char variables.
??? What are you speaking about here? Argument passing is
different. Because of the way C allows to pass any kind of arguments,
it require them to be all aligned the same. Register have nothing to
do here (but perhaps on heavily optimizing compilers on architectures
that have a lot of register / register windows).
> In short: the practical gain of using char for BOOL is minimal,
> especially in comparison to the already wasteful use of char instead of
> a bit.
NeXTSTEP was designed on computers with 8MB RAM. While there was
virtual memory and the constraints were not as strong as a 64KB RAM,
it's obvious that they did not was space gratuituously: the used bit
fields for boolean attributes as much as possible in all classes.
> b) even char is as wasteful requiring 8 times the memory necessary
> (which is why everyone is using bitfields anyway) - apparently it is
> worth that
By the way, I'm sure we can find some BOOL value stored in a 1-bit field.
> PS: this discussion is a lot of fun - and I indeed learned a lot I
> didn't knew before ;-)
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Richard Frith-Macdonald, 2004/02/01
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), David Ayers, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Richard Frith-Macdonald, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Richard Frith-Macdonald, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Helge Hess, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Nicola Pero, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Pascal J . Bourguignon, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Helge Hess, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Pascal J . Bourguignon, 2004/02/03
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?),
Pascal J . Bourguignon <=
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Richard Frith-Macdonald, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Helge Hess, 2004/02/02
- Re: [RFA]: BOOL coding standards (Was: Problem with +numberWithBool: ?), Pascal J . Bourguignon, 2004/02/02