"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsc15dnaa5a2sq9@digitalmars.com...
> Sorry I didn't see your reply before I posted Matthew... So what you're saying is, that is a developer has this
>
> struct A {
>    bool b[2];
>    int  i;
> }
>
> in a C app, they re-write that app in D, using the same struct, the binary representation of that struct will not be the same as in the C app.
>
> What about if they code their D as..
>
> extern (C) {
>    struct A {
>      bool b[2];
>      int i;
>    }
> }
>
> will it look the same then? Doesn't the extern C above tell the D compiler to use the C padding rules etc.

I have no idea. But don't you think that even if it does it "correctly", i.e. the packing of structures corresponds to what C knows a bool to be - and bear in mind that bool in C and bool in D are quite different beasts (esp. since in C it is implementation dependent)  - then you've got different-semantic flavours - one can be addressed, the other cannot - of the same type within D.

IMO, it's all just too damn hideous. bit is a wart, and should be abandoned entirely, in favour of bit fields for individual elements, and library-based packed containers.


>
> Regan
>
> On Sat, 21 Aug 2004 12:56:28 +1200, Regan Heath <regan@netwin.co.nz> wrote:
>
> > On Fri, 20 Aug 2004 17:45:50 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:
> >> In article <cg4sr6$9ur$1@digitaldaemon.com>, Matthew says...
> >>>
> >>> Because it would be unpleasantly inconsistent. D is already fragile in
> >>> so far as one cannot include C headers into D
> >>> source. If we then compound this disconnect by having not only
> >>> different names for things, but having to match up bit
> >>> variables in D with bitfields in C, it'll just be untenable.
> >>
> >> But D bit types are stored as bytes unless they're in an array, in
> >> which case
> >> they're arrays of packed bytes.  AFAIK this should dovetail quite well
> >> with the
> >> bool type in C/C++, which is typically stored in a byte as well.  Is
> >> this really
> >> much of a problem?
> >
> > Perhaps if Matthew gave an example of what he thinks is a problem we could discuss what we think is going on, Walter could tell us what actually is going on, and if we do indeed stumble across a problem, we can find a solution.
> >
> > Here is what I have been playing with.. where am I going wrong.
> >
> > import std.stdio;
> >
> > extern(C)
> > {
> >    struct A {
> >      bool array[10];
> >    }
> > }
> >
> > struct B {
> >    bit[10] array;
> > }
> >
> > void main()
> > {
> >    bit[] p;
> >    A a;
> >    B b;
> >
> >    a.array[1] = true;
> >    a.array[3] = true;
> >    a.array[5] = true;
> >    a.array[7] = true;
> >    a.array[9] = true;
> >
> >    b.array[0] = true;
> >    b.array[2] = true;
> >    b.array[4] = true;
> >    b.array[6] = true;
> >    b.array[8] = true;
> >
> >    p = a.array;
> >    printf("A: ");
> >    foreach(bit b; p)
> >    printf("%d ",cast(int)b);
> >    printf("\n");
> >
> >    printf("B: ");
> >    foreach(bit b; b.array)
> >      printf("%d ",cast(int)b);
> >    printf("\n");
> >
> >    b.array[] = cast(bit[])a.array;
> >
> >    printf("B: ");
> >      foreach(bit b; b.array)
> >        printf("%d ",cast(int)b);
> >    printf("\n");
> > }
> >
> > Regan
> >
>
>
>
> -- 
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsc15dnaa5a2sq9@digitalmars.com...
> Sorry I didn't see your reply before I posted Matthew... So what you're saying is, that is a developer has this
>
> struct A {
>    bool b[2];
>    int  i;
> }
>
> in a C app, they re-write that app in D, using the same struct, the binary representation of that struct will not be the same as in the C app.
>
> What about if they code their D as..
>
> extern (C) {
>    struct A {
>      bool b[2];
>      int i;
>    }
> }
>
> will it look the same then? Doesn't the extern C above tell the D compiler to use the C padding rules etc.

I have no idea. But even if it does it "correctly", i.e. the packing of structures corresponds to what C knows a bool to be - and bear in mind that bool in C and bool in D are quite different beasts (esp. since in C its size is implementation dependent!!) - we're still in stuck a bad dream. Now we've got *different*-semantic flavours - one can be addressed, the other cannot - of the *same* type *within* a single D source file!!

IMO, it's all just too damn hideous to contemplate. Imagine explaining all this crap to someone who'd chosen Java over C++ but heard that D was C++ without all the scary bits and so wanted to try it out. He'd think we were morons.

bit is a wart, and should be abandoned entirely, in favour of bit fields for individual elements and library-based packed containers.


>
> Regan
>
> On Sat, 21 Aug 2004 12:56:28 +1200, Regan Heath <regan@netwin.co.nz> wrote:
>
> > On Fri, 20 Aug 2004 17:45:50 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:
> >> In article <cg4sr6$9ur$1@digitaldaemon.com>, Matthew says...
> >>>
> >>> Because it would be unpleasantly inconsistent. D is already fragile in
> >>> so far as one cannot include C headers into D
> >>> source. If we then compound this disconnect by having not only
> >>> different names for things, but having to match up bit
> >>> variables in D with bitfields in C, it'll just be untenable.
> >>
> >> But D bit types are stored as bytes unless they're in an array, in
> >> which case
> >> they're arrays of packed bytes.  AFAIK this should dovetail quite well
> >> with the
> >> bool type in C/C++, which is typically stored in a byte as well.  Is
> >> this really
> >> much of a problem?
> >
> > Perhaps if Matthew gave an example of what he thinks is a problem we could discuss what we think is going on, Walter could tell us what actually is going on, and if we do indeed stumble across a problem, we can find a solution.
> >
> > Here is what I have been playing with.. where am I going wrong.
> >
> > import std.stdio;
> >
> > extern(C)
> > {
> >    struct A {
> >      bool array[10];
> >    }
> > }
> >
> > struct B {
> >    bit[10] array;
> > }
> >
> > void main()
> > {
> >    bit[] p;
> >    A a;
> >    B b;
> >
> >    a.array[1] = true;
> >    a.array[3] = true;
> >    a.array[5] = true;
> >    a.array[7] = true;
> >    a.array[9] = true;
> >
> >    b.array[0] = true;
> >    b.array[2] = true;
> >    b.array[4] = true;
> >    b.array[6] = true;
> >    b.array[8] = true;
> >
> >    p = a.array;
> >    printf("A: ");
> >    foreach(bit b; p)
> >    printf("%d ",cast(int)b);
> >    printf("\n");
> >
> >    printf("B: ");
> >    foreach(bit b; b.array)
> >      printf("%d ",cast(int)b);
> >    printf("\n");
> >
> >    b.array[] = cast(bit[])a.array;
> >
> >    printf("B: ");
> >      foreach(bit b; b.array)
> >        printf("%d ",cast(int)b);
> >    printf("\n");
> > }
> >
> > Regan
> >
>
>
>
> -- 
> Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

On Sat, 21 Aug 2004 11:17:07 +1000, Matthew <admin.hat@stlsoft.dot.org> wrote:
<snip>
>> will it look the same then? Doesn't the extern C above tell the D compiler
>> to use the C padding rules etc.
>
> I have no idea. But don't you think that even if it does it "correctly", i.e. the packing of structures corresponds to
> what C knows a bool to be - and bear in mind that bool in C and bool in D are quite different beasts (esp. since in C it
> is implementation dependent)

If it's implementation dependant then how does D work with a C++ lib that contains a struct that contains an array of bools? Or does the obj file data include offsets and lengths?

> - then you've got different-semantic flavours - one can be addressed, the other cannot -
> of the same type within D.

This isn't a biggee really, so long as you know the behaviour.

> IMO, it's all just too damn hideous. bit is a wart, and should be abandoned entirely, in favour of bit fields for
> individual elements, and library-based packed containers.

Yeah.. just thinking about this.. what if you have:

struct A {
  ubyte  a;
  ushort b;
  uint   c;
  ulong  d;
}

then allow us to reference the bits of each type as if the type were an array of bits, example:

void main()
{
  A a;

  foreach(bit b; a.a)
    ..

  a.c[8..16] = a.a[];

  ..etc..
}

This would require some compiler magic, it appears to me that there are 3 possibilities for implementing it:

1. all basic types are actually stored as arrays of bits.
2. the arrays are created/destroyed when required.
3. a keyword is introduced to cause #1 above when needed. 'bitmask' for example.

3 is clearly the best choice IMHO.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Matthew wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsc15dnaa5a2sq9@digitalmars.com...
>
>>What about if they code their D as..
>>
>>extern (C) {
>>   struct A {
>>     bool b[2];
>>     int i;
>>   }
>>}
>>
>>will it look the same then? Doesn't the extern C above tell the D compiler
>>to use the C padding rules etc.
> 
> I have no idea. But even if it does it "correctly", i.e. the packing of structures corresponds to what C knows a bool to
> be - and bear in mind that bool in C and bool in D are quite different beasts (esp. since in C its size is
> implementation dependent!!) - we're still in stuck a bad dream. Now we've got *different*-semantic flavours - one can be
> addressed, the other cannot - of the *same* type *within* a single D source file!!

IMO the bool alias is what's causing some of the problems.  Perhaps it should be an alias for ubyte rather than bit?  Only issue there is that it would probably confuse people.

> IMO, it's all just too damn hideous to contemplate. Imagine explaining all this crap to someone who'd chosen Java over
> C++ but heard that D was C++ without all the scary bits and so wanted to try it out. He'd think we were morons.
> 
> bit is a wart, and should be abandoned entirely, in favour of bit fields for individual elements and library-based
> packed containers.

I'm of two minds on the bit issue.  I actually like the convenience and efficiency of a language implementation, and I think the name "bit" is perfectly clear.  On the other hand, I don't like special cases (array member addressing), especially when templates are involved.  How about this for fun:

# extern(C) bool foo();
# bit x = true;
# if( x == foo() ) {...}

Are there C implementations that represent TRUE as 0xFF instead of 0x1?  Assuming there are, the above if statement should never be evaluated, even though the programmer intends it to be.


Sean

Sean

Just checking. Did you get my email re unit-tests?

No need to hurry on a reply. Just wanted to know you got it, email being increasingly unreliable these days ....


"Sean Kelly" <sean@f4.ca> wrote in message news:cg6a22$12ag$1@digitaldaemon.com...
> Matthew wrote:
> > "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsc15dnaa5a2sq9@digitalmars.com...
> >
> >>What about if they code their D as..
> >>
> >>extern (C) {
> >>   struct A {
> >>     bool b[2];
> >>     int i;
> >>   }
> >>}
> >>
> >>will it look the same then? Doesn't the extern C above tell the D compiler to use the C padding rules etc.
> >
> > I have no idea. But even if it does it "correctly", i.e. the packing of structures corresponds to what C knows a
bool to
> > be - and bear in mind that bool in C and bool in D are quite different beasts (esp. since in C its size is implementation dependent!!) - we're still in stuck a bad dream. Now we've got *different*-semantic flavours - one
can be
> > addressed, the other cannot - of the *same* type *within* a single D source file!!
>
> IMO the bool alias is what's causing some of the problems.  Perhaps it should be an alias for ubyte rather than bit?  Only issue there is that it would probably confuse people.
>
> > IMO, it's all just too damn hideous to contemplate. Imagine explaining all this crap to someone who'd chosen Java
over
> > C++ but heard that D was C++ without all the scary bits and so wanted to try it out. He'd think we were morons.
> >
> > bit is a wart, and should be abandoned entirely, in favour of bit fields for individual elements and library-based packed containers.
>
> I'm of two minds on the bit issue.  I actually like the convenience and efficiency of a language implementation, and I think the name "bit" is perfectly clear.  On the other hand, I don't like special cases (array member addressing), especially when templates are involved.  How about this for fun:
>
> # extern(C) bool foo();
> # bit x = true;
> # if( x == foo() ) {...}
>
> Are there C implementations that represent TRUE as 0xFF instead of 0x1?
>   Assuming there are, the above if statement should never be evaluated,
> even though the programmer intends it to be.
>
>
> Sean

Matthew wrote:

> Sean
> 
> Just checking. Did you get my email re unit-tests?
> 
> No need to hurry on a reply. Just wanted to know you got it, email being increasingly unreliable these days ....

No I didn't.  Not sure why, unless SpamAssassin tossed it before it hit my inbox.  Please re-send it if it's handy.


Sean

"Sean Kelly" <sean@f4.ca> wrote in message news:cg6b6n$12rg$1@digitaldaemon.com...
> Matthew wrote:
>
> > Sean
> >
> > Just checking. Did you get my email re unit-tests?
> >
> > No need to hurry on a reply. Just wanted to know you got it, email being increasingly unreliable these days ....
>
> No I didn't.  Not sure why, unless SpamAssassin tossed it before it hit my inbox.  Please re-send it if it's handy.

No, not SpamAssassin. Age, and its wearying effects on ones competence.

Now sent. Let me know if you've not received in 10 mins.

"Matthew" <admin.hat@stlsoft.dot.org> escribió en el mensaje
news:cg4blj$1uf$1@digitaldaemon.com
| Well, I don't think it should crash, but one would presume bit is not allowed
in
| struct or union types, since it has no meaning in C.
|
| If that's not the case, then it should be.
|
|
| "Carlos Santander B." <carlos8294@msn.com> wrote in message
| news:cg41gm$2u2d$1@digitaldaemon.com...
|| Given the following code:
||
|| /////////////////////
|| struct X
|| {
||     bit flag;
|| }
||
|| void main ()
|| {
||     X x;
||     x.flag = 0 != 0;
|| }
||
|| /////////////////////
||
|| dmd outputs: "Internal error: ..\ztc\cgcs.c 213". If X is a union the problem
|| remains, but not if it's a class.
||
|| -----------------------
|| Carlos Santander Bernal

However it compiled before. I don't see why it shouldn't now.

And I see Andy posted the exact same error. Sorry about that.

-----------------------
Carlos Santander Bernal

"Sean Kelly" <sean@f4.ca> wrote in message news:cg6a22$12ag$1@digitaldaemon.com...
> Matthew wrote:
> > "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsc15dnaa5a2sq9@digitalmars.com...
> >
> >>What about if they code their D as..
> >>
> >>extern (C) {
> >>   struct A {
> >>     bool b[2];
> >>     int i;
> >>   }
> >>}
> >>
> >>will it look the same then? Doesn't the extern C above tell the D compiler to use the C padding rules etc.
> >
> > I have no idea. But even if it does it "correctly", i.e. the packing of structures corresponds to what C knows a
bool to
> > be - and bear in mind that bool in C and bool in D are quite different beasts (esp. since in C its size is implementation dependent!!) - we're still in stuck a bad dream. Now we've got *different*-semantic flavours - one
can be
> > addressed, the other cannot - of the *same* type *within* a single D source file!!
>
> IMO the bool alias is what's causing some of the problems.  Perhaps it should be an alias for ubyte rather than bit?  Only issue there is that it would probably confuse people.
>
> > IMO, it's all just too damn hideous to contemplate. Imagine explaining all this crap to someone who'd chosen Java
over
> > C++ but heard that D was C++ without all the scary bits and so wanted to try it out. He'd think we were morons.
> >
> > bit is a wart, and should be abandoned entirely, in favour of bit fields for individual elements and library-based packed containers.
>
> I'm of two minds on the bit issue.  I actually like the convenience and efficiency of a language implementation, and I think the name "bit" is perfectly clear.  On the other hand, I don't like special cases (array member addressing), especially when templates are involved.  How about this for fun:
>
> # extern(C) bool foo();
> # bit x = true;
> # if( x == foo() ) {...}
>
> Are there C implementations that represent TRUE as 0xFF instead of 0x1?
>   Assuming there are, the above if statement should never be evaluated,
> even though the programmer intends it to be.

Everything that one would want from a bit type - which is only the packing of more than one of them into sub-byte sizes, and only being able to logically hold two values - can be obtained by a library. So why does it remain in the library, when one considers the number of other useful things that could be in the language but are instead done as libraries? My guess is its Walter's fondness for it.

I don't object to Walter having warts in his work for sentimental reasons. Anyone willing to invest a couple of hours browsing STLSoft (or much of my other works) will doubtless point out several of my own. But this language specifically sets out to address the mistakes and unfortunate accretions of C and C++. Given _that_, bit just makes D look foolish. I'd prefer if we make its critics work a bit harder for their material.

"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg681o$11c3$1@digitaldaemon.com...
> I have no idea. But even if it does it "correctly", i.e. the packing of
structures corresponds to what C knows a bool to
> be - and bear in mind that bool in C and bool in D are quite different
beasts (esp. since in C its size is
> implementation dependent!!) - we're still in stuck a bad dream. Now we've
got *different*-semantic flavours - one can be
> addressed, the other cannot - of the *same* type *within* a single D
source file!!
>
> IMO, it's all just too damn hideous to contemplate. Imagine explaining all
this crap to someone who'd chosen Java over
> C++ but heard that D was C++ without all the scary bits and so wanted to
try it out. He'd think we were morons.
>
> bit is a wart, and should be abandoned entirely, in favour of bit fields
for individual elements and library-based
> packed containers.

I have no idea why this is a problem - all you have to do to match a C struct is to use the corresponding D type that matches the size of the corresponding C type. That means you'll have to look up what a 'bool' is for your C implementation, and then use the D type that matches. It is no different at all than looking up the size of 'unsigned' in your C implementation and then choosing ushort, uint, or ulong in D to match.