Wearing my heretical pragmatist hat, may I pose the question: why do we have a bit type? I am at a loss to think why it is useful (or more useful than bit fields).

I'll concede that I've not done any comms programming for some time, so maybe the "totally bleeding obvious" reason has slipped my memory.

Yours, ready to be informed

Matthew

"Frank Wills" <fdwills@sandarh.com> wrote in message news:bgk5n1$bs2$1@digitaldaemon.com...
>
> Mike,
>
> Sure, sure, yes, yes, I imagine that most
> people on this list understand everything you
> are explaining, and the issues involved
> (who on this list doesn't know what a bit is,
> and that it is a part of a larger addressable
> unit in memory?)
>
> I just wanted to know (from Walter):
>   1) Why "out" isn't currently implemented for
> bit parameters.
>   1 - Walter's answer) It sounds like it will or
> could be, if and when he gets to it. And that
> there's just more work to implementing the bit
> type in various manners. Obviously there are
> no 'bit' addressable memory units in memory,
> it must be 'extracted' from larger units (I'm
> not telling anyone anything new here am I?)
>
>   2) Bit pointers __do__ currently work. Does
> Walter __intend__ for them to work, or are
> they just happening to work.
>   2 - Walter's answer) It sounds like he may
> do something to better refine the use of
> bit pointers. I don't yet know if he intended
> for them to work at this point at all.
>
> Mike Wynn wrote:
> > which bit is the bit ?
> > consider;
> > void func( out bit rv, int i ) { ... }
> > void meth() {
> >     bit a,b, c;
> >     func(a, 0 );func(b, 3 );func(c, 6 );
> > }
> > a,b,c might be bits 0,1,2 of the first stack word
> > shift and mask to the in is always bit0 is o.k.
> > but you either have to pass the ptr to the storage word/dword and the
> > position to save to
> > or have copy on return (which might mess up some code).
> > I believe there is no bit*
> > which would be struct ( int pos, int * storePtr; } similar to array.
> >
> > "Frank Wills" <fdwills@sandarh.com> wrote in message news:bgiv3n$2ati$1@digitaldaemon.com...
> >
> >>No out bit parameters: I can work
> >>around this, but I was curious about
> >>the reason. Is it just technical?
> >>
> >>I like to have certain functions
> >>return a bit value for success or
> >>failure, and use an out parameter
> >>to return results.
> >>
> >>bit someFunc(out char[] result)
> >>but
> >>bit someFunc(out bit result)
> >>isn't allowed.
> >>
> >
> >
> >
>

Matthew Wilson wrote:

> Wearing my heretical pragmatist hat, may I pose the question: why do we have
> a bit type? I am at a loss to think why it is useful (or more useful than
> bit fields).

Its semantics are for boolean.  It should be renamed - I want "boolean", as "bool" is just lazy.  Walter, is there any reason why it hasn't been renamed?

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bgkdol$ish$1@digitaldaemon.com...
> Matthew Wilson wrote:
>
> > Wearing my heretical pragmatist hat, may I pose the question: why do we
have
> > a bit type? I am at a loss to think why it is useful (or more useful
than
> > bit fields).
>
> Its semantics are for boolean.  It should be renamed - I want "boolean", as "bool" is just lazy.  Walter, is there any reason why it hasn't been renamed?

I could not agree more.

It should be called boolean, it should not be a bit, it should be the same size as int, and any writing of the literal 'true' in (sub-)expressions should be automatically translated by the compiler to the inverse expression involving 'false', thereby avoiding the potential dangers of tri-state bool in C++.

Furthermore, (now you've got me going!), all conditional (sub-)expression
should have to be _explicitly_ boolean. Hence

boolean    b;
int            i;

if( b &&
   i)   // compiler error
{}

if( b &&
    i != 0)   // ok
{}

But I realise that all the obfuscators will *never* swallow that one, so just give me the first paragraph of requirements above, and I'll be quiet.

Matthew

"Matthew Wilson" <matthew@stlsoft.org> ha scritto nel messaggio news:bgkeft$jk9$1@digitaldaemon.com...
> It should be called boolean, it should not be a bit, it should be the same size as int, and any writing of the literal 'true' in (sub-)expressions should be automatically translated by the compiler to the inverse
expression
> involving 'false', thereby avoiding the potential dangers of tri-state
bool
> in C++.

Maybe it could be a "real" bit when it's an element in an array. Once you
have the starting address and index, automatic bit masking is not that hard
to implement.
Besides, why not make it 1 byte in size, or at least have a compiler option
which lets you do it?

> Furthermore, (now you've got me going!), all conditional (sub-)expression
> should have to be _explicitly_ boolean. [...]

I see the point. That's going to be a hard battle though...

Ric

"Frank Wills" <fdwills@sandarh.com> wrote in message news:bgk5n1$bs2$1@digitaldaemon.com...
>
> Mike,
>
> Sure, sure, yes, yes, I imagine that most
> people on this list understand everything you
> are explaining, and the issues involved
> (who on this list doesn't know what a bit is,
> and that it is a part of a larger addressable
> unit in memory?)

I appologise, just giving what I could remember from the answer I got from
Walter when I tried `out bit b` ages ago.
I assumed no out bit meant no bit * too, so never bothered with bit * as a
solution (or inout bit)

I think I know what you mean, but "part of a larger addressable unit in
memory"
bits is smallest sub part of the addressable units of the CPU,
isnt it more that all CPU's (that I've used) only allow direct addressing to
multi bit quantities units
I assumed everyone know that, as they all knew most RISC cpus can only
address units at unit alignment.

I'm in the drop bit and give us a boolean conceptual type camp.
or if you can have bit *, bit[] give us full useage of it, allow an int to
be cast to a bit[] and vice-versa
or even a int[] to a bit[] and allow set scanning etc in the bit[].
as I've said before I believe a language should be driven by its semantics
and not its implementation
the better you can tell a compiler what you want done (rather than how) the
better the chances the compiler can optimise your code.

my desire for boolean is that the storage of a boolean in undefined, so
extern C api's
which use int for boolean and D code with booleans can interoperate without
the need to cast.

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bgkdol$ish$1@digitaldaemon.com...
> Matthew Wilson wrote:
> > Wearing my heretical pragmatist hat, may I pose the question: why do we
have
> > a bit type? I am at a loss to think why it is useful (or more useful
than
> > bit fields).
> Its semantics are for boolean.  It should be renamed - I want "boolean", as "bool" is just lazy.  Walter, is there any reason why it hasn't been renamed?

I've put a bool alias for bit in 0.69. I found "bit" to be appealing, as there is the implication that there is none of this tri-state confusion nonsense we find in C, but others obviously don't see it that way. "bool" is used in C and C++.

"Walter" <walter@digitalmars.com> wrote in message news:bglv4d$1vvn$2@digitaldaemon.com...
>
> "Burton Radons" <loth@users.sourceforge.net> wrote in message news:bgkdol$ish$1@digitaldaemon.com...
> > Matthew Wilson wrote:
> > > Wearing my heretical pragmatist hat, may I pose the question: why do
we
> have
> > > a bit type? I am at a loss to think why it is useful (or more useful
> than
> > > bit fields).
> > Its semantics are for boolean.  It should be renamed - I want "boolean", as "bool" is just lazy.  Walter, is there any reason why it hasn't been renamed?
>
> I've put a bool alias for bit in 0.69. I found "bit" to be appealing, as there is the implication that there is none of this tri-state confusion nonsense we find in C, but others obviously don't see it that way. "bool"
is
> used in C and C++.
>
the C bool as an alias to int is poor (again its implementation over
symantics)
the Java boolean is what we want (I do): storage and implementation are
undefined only the semantics are defined.
it can be only true or false, and if cast to a numeric value then false ===
0 true === 1 (like C where !!int is 0 or 1 )  to cast a pointer or reference
(object or array) to boolean is equiv to b = (o === null) ? false : true;
all compare ops return they type boolean not bit.
I've no objection to bit and bit[] (although think if you have them then
they should be complete [that is int to bit array and bit array slice to int
operations, along with inout, out and pointer to bit])
I have the same "problem" with char/wchar[] as strings to me string is a
concept and char[] implementation.

Walter wrote:
> "Burton Radons" <loth@users.sourceforge.net> wrote in message
> news:bgkdol$ish$1@digitaldaemon.com...
> 
>>Matthew Wilson wrote:
>>
>>>Wearing my heretical pragmatist hat, may I pose the question: why do we
> 
> have
> 
>>>a bit type? I am at a loss to think why it is useful (or more useful
> 
> than
> 
>>>bit fields).
>>
>>Its semantics are for boolean.  It should be renamed - I want "boolean",
>>as "bool" is just lazy.  Walter, is there any reason why it hasn't been
>>renamed?
> 
> 
> I've put a bool alias for bit in 0.69. I found "bit" to be appealing, as
> there is the implication that there is none of this tri-state confusion
> nonsense we find in C, but others obviously don't see it that way. "bool" is
> used in C and C++.

"boolean" describes its semantics without bringing in either unfortunate comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bgmfml$2fr1$1@digitaldaemon.com...
> > I've put a bool alias for bit in 0.69. I found "bit" to be appealing, as there is the implication that there is none of this tri-state confusion nonsense we find in C, but others obviously don't see it that way.
"bool" is
> > used in C and C++.
> "boolean" describes its semantics without bringing in either unfortunate
> comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).

What wrong impression does bit give? I'm a bit (!) flummoxed as to why people find bit so distasteful.

I think that a 'bit' gives the impression that it will always be implemented as one element of an eight-element byte. That's the impression that I get from using a 'bit'. I don't know if that's how it's implemented in DMD, but that's how I think of it: as a tiny unit of memory.

Now, a 'boolean' is not a unit of memory as all. It's a semantic term given to a true/false condition. I don't care how a boolean is implemented, as long as it has two-and-only-two values: true and false, and as long as it provides me a mechanism for flipping between the two values.

If you're a compiler vendor (and you are), I don't care whether you implement
the boolean primitive type as a bit or as an 8-bit type, if that makes
addressing and dereferencing more efficient. Let the compiler do whatever it
wants with boolean types as long as I can get sizeof(boolean) to know how many
bits (or bytes) are taken up by the type. However, if I call sizeof(bit), it
should be exactly the same on every platform (.125).

I don't know if anybody else is on the same page as me, but these are the reasons that I'd like to have a boolean type instead of just a bit type. Of course, I'd like to have _both_ bits and booleans (please just don't call it 'bool'), since bits (and bit arrays) could be useful for their own purposes. But I'd prefer to keep my true/false values in a boolean than in a bit.

In article <bgmnb5$2n2b$1@digitaldaemon.com>, Walter says...
>
>
>"Burton Radons" <loth@users.sourceforge.net> wrote in message news:bgmfml$2fr1$1@digitaldaemon.com...
>> > I've put a bool alias for bit in 0.69. I found "bit" to be appealing, as there is the implication that there is none of this tri-state confusion nonsense we find in C, but others obviously don't see it that way.
>"bool" is
>> > used in C and C++.
>> "boolean" describes its semantics without bringing in either unfortunate
>> comparisons (bool, Windows' BOOL) or completely wrong impressions (bit).
>
>What wrong impression does bit give? I'm a bit (!) flummoxed as to why people find bit so distasteful.
>
>