"Arcane Jill" wrote...
>
> Can I just add at this point that in all my life, I have never seen an
array of
> boolean truth values.

Whereas I actually see it all the time. Of course, it could just be my university lecuters and their examples....

-- 
Experience is a good school but the fees are high.
    - Heinrich Heine

"Walter" wrote...
>
> What's the problem with converting them to int? Why pretend it isn't what
it
> is, a 1 or a 0? I've built TTL hardware, single board computers from scratch, etc., and 0/1, true/false, on/off, yes/no, +5V/0V are all the
same
> in my mind. (In fact, the only reason true and false are keywords in D is not because they are that useful, but because so many programmers believe they are useful <g> and would otherwise produce multiple conflicting definitions of them. It's also there to drive a stake in the heart of the execrable BASIC convention that true is 0xFFFF, and to thwart the equally miserable attempts to make tristate or even quadstate 'bools'.)
>

Yeah but like with C before it had it's bool keyword, people is already producing multiple conflicting definitions of them here....  :S

-- 
Experience is a good school but the fees are high.
    - Heinrich Heine

It'd be boring any other way, don't ya think? <g>

"Walter" <newshound@digitalmars.com> wrote in message news:c9mnfn$1tc9$1@digitaldaemon.com...
> We'll just agree to disagree, then.
>
>

> > 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.
>
> My guess is, one of the reasons why Walter defined bool as an alias for bit was precisely to *prevent* people from defining it as an alias for int. However, Matthew immediately counter-attacked by defining a type called boolean which is an alias for int.

Your characterisation is, if not entirely satire, disengenuous. D is a language, like C and C++, that provides powerful extensibility mechanisms to allow developers to expand/enhance it at their own discretion. D does not require, any more than C or C++, that every such extension be ratified by the author of the language.

> Walter can continue this battle by officially defining boolean as an alias for bit as well, and then Matthew will be forced to give his alias for int an awkward name like matthewsbool, or maybe truefalse.

Incorrect. The boolean's I have defined - apart from being stop-gaps to what I still (albeit weakly) hope will be a real one - are defined within modules. Unless Walter does some amazingly prescient word-reserving he cannot stop me or anyone else from defining our own strongly typed boolean.

> Like many people who post to this group, I like the idea of a strongly-typed boolean type. But the language doesn't define one. So I move on.

I think you've mistaken who's got the dose of stasis here. I resigned myself months ago to there being virtually no hope to the bool issue, and have moved on. Were that not the case, then I wouldn't have written any libraries in that time.

As I've said several times now, I can accept Walter saying that it's his language, and he's put his foot down, and bool will never be strongly typed (wrt integral types). That's fine by me. There are things I've done/not done with my libraries despite other people's requests/criticisms. When one is putting in the bulk of the effort, one gets to have the last say. Since he's almost said that many times, I have moved on, and I don't expect it to ever change.

However, I do not accept some of the pretty weak arguments to its support - Walter's recent code examples being a great illustration - and until I'm blocked from this NG I'm going to counter such arguments when they're put up. Maybe I've misunderstood what NGs are about, but in my estimation they're not about sucking up opinions you believe to be patently false/absurd just because you (or anyone else) happens to have a high degree of respect for the person offering them.

Walter know's in what regard I hold him, both as an engineer and as a person. He was an invaluable reviewer of Imperfect C++, and I've asked him to do the same on my next book. (Never mind the fact that we're going to be writing one together real soon!) But on this issue I believe he's wrong. Should I not say so just because there are several other areas of software engineering where I know his knowledge outstrips mine? You take a group of 100 experienced developers - they'll each know many things the others do not. Which one's get to speak, which one's must be silent? Sounds ludicrous to me.

Let me give you another example. Walter and I are both entirely happy with printf(). I can't speak for him, but I know that I'm wrong, and that printf() is bad for D. I only like it, and am comfortable with it, because I have a lot of experience with it and to me - though not to many others, I concede - it is second nature and perfectly safe to use.

Any experienced engineer is going to have a fondness for things that are, in an objective estimation, simply wrong/bad/dangerous/setting-a-bad-example. Such is life. I can respect such positions. But I don't respect attempts to justify such partiality. Why not just fess up? It's a simpler existence in the long run. (e.g. it'd have shut me up on this issue months ago. <g>)

> Instead of using bool, I use bit. Bool is just an alias for bit
> anyway, so why bother with bool? Just use bit, and move on. But what if
> I absolutely *must* have an int-based bool for performance reasons? Just
> use int, and move on.

Are you telling me that there's no - that's 0% - advantage to be had by using aliases / weak typedefs?

> What about Matthew's boolean type? I think that this type just creates confusion and inconsistency. Is D going to have *three* boolean types now, bit, bool and boolean? Let's cut this proliferation of boolean types off at the beginning. Just use bit (or if necessary, int).
>
> But what about the strongly-typed boolean we want? By all means, keep requesting it. But the language does not define one (yet), so until and unless it does, please don't add to the confusion by trying to define your own.

If we are not to define our own type(def)s, then we should be using either Java or .NET. Is that your suggestion? Should the typedef / alias facilities be removed from D? If not, what are they there for? Please provide a "typedef For Dummies" guide, so we can learn how to program appropriately.


-- 
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)

"You can tell a Yorkshireman, but you can't tell him much!" -- Uncle Michael

-------------------------------------------------------------------------------

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.

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?


"Walter" <newshound@digitalmars.com> wrote in message news:c9lrlu$k74$1@digitaldaemon.com...
>
> "Matthew" <matthew.hat@stlsoft.dot.org> wrote in message news:c9ln6r$du0$1@digitaldaemon.com...
> > As you well know, from reviewing "Imperfect C++", I think C/C++ have made
> a grave
> > mistake by not prescribing that sizeof(bool) == sizeof(int), and why
> compiler
> > manufacturers have "utilised" that missing prescription to blunder and
> defined
> > sizeof(bool) == 1.
>
> Your argument that sizeof(bool) should be fixed and not left up to the implementation is sound, and is done in D. Your other argument that bool should be the same size as int for efficiency reasons isn't as compelling. To convert an into a bool requires something equivalent to (i?1:0), regardless of the size of the bool. Having random bool variables be int sized is no problem, but having arrays of them is a problem.
>
> > I don't advocate that D do either of these things - i.e. fail to prescribe
> the
> > size and presribe/use it as 1 - but D actually goes even further from the
> poor
> > situation with sizeof(bool), since it defines it as a bit. This merely
> compounds
> > the problems of having it as == 1, and adds the new hassles of addressing elements in arrays of "bool"s.
>
> A 'bit' by itself has a size of 1 byte. Only when turned into an array are they packed into bit positions in memory. While this doesn't address the bit array slicing problem, it seems to work rather well otherwise.
>
> > > > Also, the bit/int opEquals() point is well made.
> > > The reason for it being the int 0/!0 is because converting it to 0/1
> adds 3
> > > instructions:
> > >     cmp    EAX,1
> > >     sbb    EAX,EAX
> > >     inc    EAX
> > > When sorting/searching a lot of data, this can add up.
> > Isn't this a clear argument for why we should prefer int to bit, and,
> therefore,
> > why the bool alias should be int?
>
> No, because even if it is an int it still has to go through the (i?1:0)
> operation.
>
> > Well, I know you're skin's even thicker than mine, but you clearly _seem_
> at a
> > point of some exasperation to state that "and it's going to stay that way.
> > There's a lot of very cool stuff coming for D, and I can't wait to get it
> > implemented. I've had as much as I can take on the whole 15 years of bool
> > business".
> > That reads to me like "I'm sick of this debate. I'm not changing my mind.
> You
> > should all (let me) get on with more important things."
>
> Ok, I can see how you read it that way. But I just wanted to point out that, while it's fun debating these things, it's time for D to move on.
>
> > If conditional
> > (sub-)expressions are boolean, and not convertible to int
>
> What's the problem with converting them to int? Why pretend it isn't what it is, a 1 or a 0? I've built TTL hardware, single board computers from scratch, etc., and 0/1, true/false, on/off, yes/no, +5V/0V are all the same in my mind. (In fact, the only reason true and false are keywords in D is not because they are that useful, but because so many programmers believe they are useful <g> and would otherwise produce multiple conflicting definitions of them. It's also there to drive a stake in the heart of the execrable BASIC convention that true is 0xFFFF, and to thwart the equally miserable attempts to make tristate or even quadstate 'bools'.)
>
> > Now here's an idea. We (almost) all agree that we don't want pragmas,
> warnings or
> > compiler-options that basically change the definition of the language.
> However,
> > since we're in the pre-1.0 stage, why not allow a compiler
> flag -strict_boolean
> > that will switch on a boolean type, sub-expressions and switch off interconversions. Then we can test, rather than debate, just how beneficial/onerous this stuff would be.
>
> Having an alias of bool to int will mean that one could, for example, store '3' in a so-called bool. This is just no good. A bool needs to be constrained to be 0 or 1, or it isn't a bool. The D 'bit' type enforces this constraint, and so is the bool candidate.
>
> The basic problem is there are tradeoffs with the semantics of bool and its implementation. Any time there are tradeoffs, there will be controversy. There is no design for it that will put things to rest once and for all.
>
>
> > > Consider, for example, the following code:
> > >
> > > class A { void foo() { } }
> > > void test() { A a; a.foo(); }
> > >
> > > Which would work in C++, but fails in D. This regularly trips up people coming to D from C++. Fortunately, the code fails predictably in a
> manner
> > > that pinpoints the problem, the solution is explained, and one goes on.
> This
> > > will not happen if implicit conversion rules are changed
> >
> > Not based on any of the changes I'd want. The compiler would simply fail
> to
> > compile on the formerly-convertible expression. Nothing subtle about that.
>
> That's true for implicit narrowing conversions.
>
> > > The ABI will happen, it's just premature.
> > Understood. I didn't mean to imply that it's not going to happen, just
> that it's
> > not done so yet.
>
> It's actually quite a bit of work to write.
>
> > True. And in the spirit of that, I will formally state that, despite my disagreeing with it, I can live with the implicit conversions between bool
> and
> > int. What I cannot live with, and won't program to, is the fact that the
> boolean
> > type (or alias) bool is a bit. This means that in all my D coding I'm
> going to
> > have to continue to define the "boolean" type, based on int, albeit that I
> will
> > move (and have already in the recent upgrade of recls) from it being a
> typedef to
> > being an alias.
>
> All right.
>
> > Can you meet me (/ us) halfway, and at least change the standard alias of
> bool
> > from bit to int, and I can jettison all my "boolean"-based code?
>
> Ack <g>
>
>

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 ...



"KTC" <me@here.com> wrote in message news:c9mu1m$26d3$1@digitaldaemon.com...
>
> "Arcane Jill" wrote...
> >
> > Can I just add at this point that in all my life, I have never seen an
> array of
> > boolean truth values.
>
> Whereas I actually see it all the time. Of course, it could just be my university lecuters and their examples....
>
> -- 
> Experience is a good school but the fees are high.
>     - Heinrich Heine
>
>

Les Baker wrote:

>> 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".

There should be only one bool (with possible aliases) - otherwise the library becomes unusable. Users will always have to ask themselves "do I pass a bool or a Bool? do I provide overloaded methods accepting bool and Bool or do I just choose one? which one?" It is much better long-term to just choose one globally.

> <opinion> "bool" being an alias for bit seems to open the way for implementation-defined quirks to pop up. Same with int. The programmer shouldn't need to worry about implementation issues (or how badly his fellow coder/coworker can stretch the rules) for what seems to be such a narrowly-defined logical type. </opinion>
> 
> (Could be 100% off-base here... don't flame too hard. Just my $0.02)
> 
> Les Baker

"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

-------------------------------------------------------------------------------

James McComb wrote:

> 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.
> 
> My guess is, one of the reasons why Walter defined bool as an alias for bit was precisely to *prevent* people from defining it as an alias for int. However, Matthew immediately counter-attacked by defining a type called boolean which is an alias for int.

I doubt that was one of Walter's intentions - I think people complained about the readability of "bit" and requested a more standard word like "bool" or "boolean" or something like that. Since aliases are excellent and providing readability he made an alias.

> Walter can continue this battle by officially defining boolean as an alias for bit as well, and then Matthew will be forced to give his alias for int an awkward name like matthewsbool, or maybe truefalse.

I don't see this as a battle. The project would never have gotten this far if Walter and/or Matthew behaved like that.

> Like many people who post to this group, I like the idea of a strongly-typed boolean type. But the language doesn't define one. So I move on. Instead of using bool, I use bit. Bool is just an alias for bit anyway, so why bother with bool? Just use bit, and move on. But what if I absolutely *must* have an int-based bool for performance reasons? Just use int, and move on.

agreed.

> What about Matthew's boolean type? I think that this type just creates confusion and inconsistency. Is D going to have *three* boolean types now, bit, bool and boolean? Let's cut this proliferation of boolean types off at the beginning. Just use bit (or if necessary, int).

Since bool is an alias technically it is not another type. There is still just one boolean type in D (aside from std/recls and std/loader). Personally I use "bool". 99% of std uses "bit". That's ok by me (though I suppose I wish std was 100% consistent).

> But what about the strongly-typed boolean we want? By all means, keep requesting it. But the language does not define one (yet), so until and unless it does, please don't add to the confusion by trying to define your own.

In my daily work with Java and C/C++ I honestly don't remember a time when
it mattered. I guess I (and my coworkers) just pass bools around as flags
and don't get fancy. So I don't really care if it is strongly typed or not.

> James McComb

In article <c9n2o6$2cui$2@digitaldaemon.com>, Matthew says...
>
[...]
>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?

I'm not an expert, too, but I think the problem is this last assuption.
Evaluating boolean expressions based on the assumption (0, !0) is more
complicated that based on the assumption (0, 1). A logical-and could be a
bit-and, for example, while in the former case more math is needed. Representing
a bool with a bit means ensuring it's in the range (0, 1), so boolean algebra
can be optimized.
It's only a supposition, because short-circuit evaulation can complicate this
assumption. We need an expert that analyzes both implementations.

I also understand that accepting to work with (0, !0) gives somewhat surprising
results, such as:

union T
{
int i;
bool b;
};

T a;
T b;
a.i = 10;
b.i = 20;
if (a.i != b.i  &&  a.b == b.b)
{
// this is true!
}

I also don't know how to compute boolean expressions, such as the equality test between booleans, without prior converting them in the range (0, 1). Ideas?

Ciao