Matthew wrote:

>I'm with AJ. I've never seen anyone use a data structure where the compression of
>boolean types into a bit field structure was mandated by size concerns.
>  
>
>(Naturally I've seen code where things are mapped to bit fields to working with
>network protocols. But such things are specialised, and in any case I've never
>seen/heard of someone using something like a vector<bool> to map to a network
>packet.)
>
>Again, I'd be interested to hear of some real examples.
>
>The ears are open ...
>  
>
Bit arrays are particularly useful for for sets.

I've used bit fields for PVS (potentially visible sets) in hidden surface removal (HSR).  Then you need to use ZRLE as well so you can't use D's bit arrays anyway.  The amount of potential visible sets in a HSR program tends to be around n^2 where n is the number of polygons, which can be a hell of a lot of memory, particularly if not compressed.  I'm sure there are heaps of circumstances where bit arrays are very useful for keeping size down while keeping the program readable.

Often its more efficient to use a bit array then a bool array as then the cache doesn't thrash so much.  Particularly for things that need to be accessed in sequence.

-- 
-Anderson: http://badmama.com.au/~anderson/

Ok, let's get this simple. What's wrong with (true/false) for boolean expressions, as Java does?

Well, as you say, that's a bit array, rather than a bool array. However, in the context you describe one would be hard pressed to come up with a difference between a boolean and a bit.

Such examples can be seized on by either side, I suppose. To me it seems to indicate that an array of bool is still a fatuous thing, because I see what you're talking about as an array of bits. But I guess I could equally see that it's a boolean array, and that therefore bool must be a bit.

Ho hum. I sorely tire of this. :(


"J Anderson" <REMOVEanderson@badmama.com.au> wrote in message news:c9n7l9$2jq8$1@digitaldaemon.com...
> Matthew wrote:
>
> >I'm with AJ. I've never seen anyone use a data structure where the compression
of
> >boolean types into a bit field structure was mandated by size concerns.
> >
> >
> >(Naturally I've seen code where things are mapped to bit fields to working
with
> >network protocols. But such things are specialised, and in any case I've never seen/heard of someone using something like a vector<bool> to map to a network packet.)
> >
> >Again, I'd be interested to hear of some real examples.
> >
> >The ears are open ...
> >
> >
> Bit arrays are particularly useful for for sets.
>
> I've used bit fields for PVS (potentially visible sets) in hidden surface removal (HSR).  Then you need to use ZRLE as well so you can't use D's bit arrays anyway.  The amount of potential visible sets in a HSR program tends to be around n^2 where n is the number of polygons, which can be a hell of a lot of memory, particularly if not compressed. I'm sure there are heaps of circumstances where bit arrays are very useful for keeping size down while keeping the program readable.
>
> Often its more efficient to use a bit array then a bool array as then the cache doesn't thrash so much.  Particularly for things that need to be accessed in sequence.
>
> -- 
> -Anderson: http://badmama.com.au/~anderson/

In article <c9n5ik$2h0d$1@digitaldaemon.com>, Matthew says...
>
>
>"Les Baker" <lesbaker@innovaREMOVETHIS.net> wrote in message news:c9mbn7$1c1u$1@digitaldaemon.com...
>> > The D options are:
>> >
>> > 1) use bit which has only 'true' or 'false' values
>> > 2) use int which has !0 and 0 values (the C style)
>> > 3) use bool for those who don't think that bit is self-documenting <g>
>>
>> Could a fourth option be the development of a boolean type ("boolean" ?) that is packaged with Phobos, that is not implicitly convertible, disallows arithmetic operations, etc? What would be needed in the language to do so? Is it already in D (opCast, making arithemetic operators private)? I remember in CUJ reading an article Herb Sutter wrote (I think) about the "nullptr" keyword proposal, and it mentioned that several library based solutions were tried before proposing a new keyword. Maybe such a type could be a "proof-of-concept".
>
>STLSoft has a library-based version of the null pointer, which works perfectly well in all circumstances. It's explained in "Imperfect C++", and one of the publisher's reviewers, who's on the C++ standards committee, asked if he could present the material to the standards committee. I've not heard anything since that time, and suspect it'll be rejected anyway, as it has one sneaky albeit, IMO, utterly reasonable, trick. But I'd better shut up, as the publisher'll be on my back for revealing all the juicy bits from the book before it hits the shelves (Sept 9th).
>
>Matthew Wilson
>
>Author: "Imperfect C++", Addison-Wesley, 2004
>    (http://www.imperfectcplusplus.com)
>Contributing editor, C/C++ Users Journal
>    (http://www.synesis.com.au/articles.html#columns)
>STLSoft moderator
>    (http://www.stlsoft.org)
>
>"An Englishman by birth, a Yorkshireman by the grace of God" -- Michael Gibbs
>
>-------------------------------------------------------------------------------

Boolean expressions as part of the library? That's counterproductive:
As a example, one of the advantages of D is that strings are directly built into
the core.
Then, if we do the opposite with something as basic as boolean expressions, we
are improving here then screw there. Bad idea.

There are two issues at stake:

1. Whether boolean is a distinct type, not implcitly interconvertible with integral types, and which represents the type of conditional sub-expressions.

2. The sizeof the boolean type.

Your comment seems to pertain to the first. My answer is that, overall, there's nothing wrong with it, although it does lead to less terse code. I, along with almost everyone else who's voiced an opinion, am willing to swallow the verbosity to avoid the (many) implicit conversion pitfalls. Walter, alas, is not. So that's going to pretty much stay.

The second issue is one where there is more (apparent) equivocation. I believe
sizeof(bit) should be sizeof(int). Others do not. AFAICT, it's about 60:40.
Walter's in the 40 on this one as well, though, so it's still 0:100 in real
terms. <G>

Anyway, I am intending to try and divorce myself from this head-banging debate, as it's just too time consuming, and never gets any traction. If I post any more opinions, someone please remind me to save my cakehole for cake.

"Lord Syl" <Lord_member@pathlink.com> wrote in message news:c9n9e1$2mil$1@digitaldaemon.com...
> Ok, let's get this simple.
> What's wrong with (true/false) for boolean expressions, as Java does?

hellcatv@hotmail.com wrote:

> while I agree that bool is ambiguous I think most people would prefer it aliased to int rather than bit in object.d :-)

I don't think it is a good idea:

alias int bool;
bool b;
b = 5; // ?????

with bool being an alias to bit, things are more consistent:

alias bit bool;
bool b;
b = 5; // Compile time error: cannot implicitly convert int to bit


Bruno.


> can we override it in a general sense so it will compile elsewhere? (i.e.
> alias
> int bool; and not have conflicts with the bit bool in the object.d  ...
> also the last thing I would want is to have problems like libjpeg of bool
> being char somewhere and int otherwhere and bit thirdware)
> 
> --Daniel
> 
> In article <c9k035$v8g$1@digitaldaemon.com>, Arcane Jill says...
>>
>>In article <c9j8jo$2t58$1@digitaldaemon.com>, Walter says...
>>>
>>> There is no consensus, nobody agrees
>>
>>This is not true. There is almost unanimous consensus on this forum, with yourself being pretty much the only dissenter.
>>
>>There have been many different suggestions regarding *implementation* - and if you want to call that "no consensus" then that's your viewpoint - but regarding the principle that a bool is not arithmetic, if you have been following this forum, you'll know you are in a very small minority here.
>>
>>If we have to wait until someone implements the SECOND D-compiler before we see a bool type, then so be it. But I'll bet you any amount of money you like it will be in the ISO/ANSI standard which eventually supercedes the original implementation.
>>
>>I think it's a shame that you don't like the bool type, but I think it's a bigger shame that you don't see a consensus when it's staring you in the face. Unless you are defining "consensus" as "unanimous opinion" - in which case your comment "and therefore no resolution" is absurd.
>>
>>Arcane Jill
>>
>>

Matthew wrote:

>fatuous 
>  
>
Dam Matthew, half the time I read you, I have to go for the dictionary.  I feel fatuous.

-- 
-Anderson: http://badmama.com.au/~anderson/

Matthew wrote:

>I'm being quite genuine - I'd like someone to explain to me what I've missed.
>Plainly put, can anyone demonstrate a single instance where a bit-sized bool can
>be more speed efficient than an int-sized bool, when the int-sized bool is only
>ever tested as 0 or !0?
>  
>
The efficiency comes with caching and memory copying when you have more then one bit packed together.

void funcA(byte x, bit a) { ... }

void funcB(byte x, int a) { ... }


It's funcA is more efficient when copying on to the stack then funcB as A only requires 16bits and B requires 40bits.  Obviously the unpacking has a cost though, although it is often much cheaper to unpack something in the cpu registers then to have it already unpacked in memory.  Obviously efficiency can't happen at a test unless you are testing more then one packed value.

-- 
-Anderson: http://badmama.com.au/~anderson/

Arcane Jill wrote:

> I've just noticed that the keyword "bool" is accepted by the compiler. Turns out this is because it's defined in "object.d" as an alias for bit.
> 
> At the very least, this enables us to document our code, by having appropriate functions return bool instead of bit.
> 
> Walter, pending the implementation of a real non-arithmetic bool type, is
> there any chance you could change this alias from bit to int? Then at
> least opEquals() could return a bool. (Or better still, have opEquals()
> return bool).
> 

Sorry, but i am not sure if it is a good idea. A bool being aliased to int would permit things like:

bool b = 1000;

which sounds strange, IMHO.

Bruno.


> Arcane Jill

In article <c9n2o6$2cui$2@digitaldaemon.com>, Matthew says...
>
>As you (Walter) know from "Imperfect C++", and I'm sure from posts here as well, I don't ever advocate a boolean test of truth be an evaluation of == 1. Given that, where's the need, *ever*, to ensure that an int-sized boolean variable have 1 or 0. I've always maintained that such a boolean would have 0 or !0.

Technically, if a bool is represented by a single bit, then the values of 0 and 1 are equivalent to 0 and !0 :)

>Given that, I'm dumbfounded (or maybe just dumb) to understand how the int-sized
>bool ever costs more (speed) than the bit-sized bool. Conversely, I have
>previously stated how the bit-sized can have (speed) costs over the int-sized.
>
>I'm being quite genuine - I'd like someone to explain to me what I've missed. Plainly put, can anyone demonstrate a single instance where a bit-sized bool can be more speed efficient than an int-sized bool, when the int-sized bool is only ever tested as 0 or !0?

Never, as far as I know.  The size of bool is typically unspecified to allow for it to be optimally adapted to different platforms (and for space).  Performance isn't always an issue.  Though perhaps this is a case for a pragma--allow the programmer to specify the size of bool?  Assume bool is always 0 or !0 (in the case of bit this would be 0 or 1, logically if not physically) and go from there.

Sean