www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - bit fields in structs

reply "Carlos Santander B." <carlos8294 msn.com> writes:
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
Aug 19 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
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

Aug 20 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Fri, 20 Aug 2004 18:10:22 +1000, Matthew <admin.hat stlsoft.dot.org> 
wrote:
 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.

It was always my impression that structs were 'just' like C structs, not 'exactly' like C structs. What I mean is, they behave in the same ways, should be used for the same things, but, are not supposed to be identical in every way. If a struct is simply a way to lay members out in memory, and members are simply accessed by an offset then why can't you have a bit in a struct, obviously if you had only one bit, there would be 7 wasted bits, or whatever was most efficient/convenient. I don't see why allowing bits in D structs stops D from using existing C structs which won't have them. Maybe I'm missing something. Regan
 "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


-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 20 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsc06h1pg5a2sq9 digitalmars.com...
 On Fri, 20 Aug 2004 18:10:22 +1000, Matthew <admin.hat stlsoft.dot.org>
 wrote:
 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.

It was always my impression that structs were 'just' like C structs, not 'exactly' like C structs. What I mean is, they behave in the same ways, should be used for the same things, but, are not supposed to be identical in every way. If a struct is simply a way to lay members out in memory, and members are simply accessed by an offset then why can't you have a bit in a struct, obviously if you had only one bit, there would be 7 wasted bits, or whatever was most efficient/convenient. I don't see why allowing bits in D structs stops D from using existing C structs which won't have them. Maybe I'm missing something.

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. I hope I'm right in thinking that structs and unions cannot contain bit types. If they are allowed, then that's just one more example of how ill/un-thought out this particular type is.
 Regan

 "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


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

Aug 20 2004
parent reply Sean Kelly <sean f4.ca> writes:
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? Sean
Aug 20 2004
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:cg5dce$i1h$1 digitaldaemon.com...
 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?

Asked and answered, old bean. Consider the poor hapless developer who needs to upgrade his struct from C: struct X { bool b; int i; }; D: struct X { bool b; int i; } to struct X { bool b[2]; int i; }; D: struct X { bool b[2]; int i; } (Note: we're assuming pre-release modifications, of course. I'm not going to get into _that_ debate.) Something tells me that this poor soul will be left with a pretty bad taste in his mouth! In fact, there's an even nastier subtlety to this Because the default packing of such a structure would have 3 pad bytes between the bool(s) and the int, and because D zero initialises, this might not be detected early, or at all!
Aug 20 2004
parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> escribió en el mensaje
news:cg62d1$ukg$1 digitaldaemon.com
|| 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.

So should D be 100% compatible with C? I don't think that's what you meant, but
that's what I can read.

|
| Asked and answered, old bean. Consider the poor hapless developer who needs to
| upgrade his struct from
|
| C:
|
| struct X
| {
|     bool    b;
|     int        i;
| };
|
| D:
|
| struct X
| {
|     bool    b;
|     int        i;
| }
|
|
| to
|
| struct X
| {
|     bool    b[2];
|     int        i;
| };
|
| D:
|
| struct X
| {
|     bool    b[2];
|     int        i;
| }
|
| (Note: we're assuming pre-release modifications, of course. I'm not going to
get
| into _that_ debate.)
|
| Something tells me that this poor soul will be left with a pretty bad taste in
his
| mouth!
|
| In fact, there's an even nastier subtlety to this
|
| Because the default packing of such a structure would have 3 pad bytes between
the
| bool(s) and the int, and because D zero initialises, this might not be
detected
| early, or at all!

I don't see that as a problem: people will have to change many times when
converting from C to D.

- C int size is not defined, while it is in D
- C arrays are just pointers, while they're not in D
- D doesn't have "signed" or "unsigned"
- D doesn't have preprocessor
... and I think there're more

Walter and others have said that porting from C to D shouldn't just be a
copy-and-paste operation: I agree with that. So if you need C's bool[2] in D,
then use byte[2] or whatever other is the matching type.

-----------------------
Carlos Santander Bernal
Aug 25 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:cgjk94$2qb9$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> escribió en el mensaje
 news:cg62d1$ukg$1 digitaldaemon.com
 || 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.

 So should D be 100% compatible with C? I don't think that's what you meant, but
 that's what I can read.

 |
 | Asked and answered, old bean. Consider the poor hapless developer who needs
to
 | upgrade his struct from
 |
 | C:
 |
 | struct X
 | {
 |     bool    b;
 |     int        i;
 | };
 |
 | D:
 |
 | struct X
 | {
 |     bool    b;
 |     int        i;
 | }
 |
 |
 | to
 |
 | struct X
 | {
 |     bool    b[2];
 |     int        i;
 | };
 |
 | D:
 |
 | struct X
 | {
 |     bool    b[2];
 |     int        i;
 | }
 |
 | (Note: we're assuming pre-release modifications, of course. I'm not going to
 get
 | into _that_ debate.)
 |
 | Something tells me that this poor soul will be left with a pretty bad taste
in
 his
 | mouth!
 |
 | In fact, there's an even nastier subtlety to this
 |
 | Because the default packing of such a structure would have 3 pad bytes
between
 the
 | bool(s) and the int, and because D zero initialises, this might not be
 detected
 | early, or at all!

 I don't see that as a problem: people will have to change many times when
 converting from C to D.

 - C int size is not defined, while it is in D

<pedantic>Wrong. Implementation-defined is quite a different beastie from undefined</pedantic>
 - C arrays are just pointers, while they're not in D

C has pointers. D has pointers. You're statement appears to address a proposition that C and D are the same somehow, or that do/must have all the same types. I have not made that proposition.
 - D doesn't have "signed" or "unsigned"

Yes it does. They're just not separated into different keywords
 - D doesn't have preprocessor

And your point is ...?
 ... and I think there're more

 Walter and others have said that porting from C to D shouldn't just be a
 copy-and-paste operation: I agree with that. So if you need C's bool[2] in D,
 then use byte[2] or whatever other is the matching type.

The salient part of my point is that there is one "common" (i.e. common-looking/feeling) type in C and D whose compatibility is warped by the fact that its vector form footprint is not a factor of its scalar footprint. You've not addressed that point at all in your post.
Aug 26 2004
parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> escribió en el mensaje
news:cgk46i$209$2 digitaldaemon.com
| "Carlos Santander B." <carlos8294 msn.com> wrote in message
| news:cgjk94$2qb9$1 digitaldaemon.com...
|| I don't see that as a problem: people will have to change many times when
|| converting from C to D.
||
|| - C int size is not defined, while it is in D
|
| <pedantic>Wrong. Implementation-defined is quite a different beastie from
| undefined</pedantic>
|
|| - C arrays are just pointers, while they're not in D
|
| C has pointers. D has pointers.
|
| You're statement appears to address a proposition that C and D are the same
| somehow, or that do/must have all the same types. I have not made that
proposition.
|
|| - D doesn't have "signed" or "unsigned"
|
| Yes it does. They're just not separated into different keywords
|
|| - D doesn't have preprocessor
|
| And your point is ...?
|
|| ... and I think there're more
||
|| Walter and others have said that porting from C to D shouldn't just be a
|| copy-and-paste operation: I agree with that. So if you need C's bool[2] in D,
|| then use byte[2] or whatever other is the matching type.
|
| The salient part of my point is that there is one "common" (i.e.
| common-looking/feeling) type in C and D whose compatibility is warped by the
fact
| that its vector form footprint is not a factor of its scalar footprint. You've
not
| addressed that point at all in your post.

Even with some errors which you pointed and that I accept, my point was that
there're many things in D and C that look similar (common, as you say) but are
different. Same with D and C++, C#, Java, and maybe others. But that doesn't
mean they should behave the same way.

You're a C++ programmer. Maybe once you'll be porting a C++ program to D, and it
has something like this:

class Foo
{
    int someVar;
};

It's a small class, but to port it to D and get the same functionality as in
C++, you have to change it:

class Foo
{
    private int someVar;
}

It's the same with other things about C++, and things about C, Java, C#...

Maybe I'm not expressing myself in the best way, but what I mean is that changes
will always have to be made. People will have to know that D does things
differently. It's like what other folks have been talking about the char type:
it's not the same as C's char. Do we change it? No: we tell people it's not the
same, so they have to think first if that's the right type. It's the same with
bool arrays (which happen to be bit arrays).

IMHO.

-----------------------
Carlos Santander Bernal
Aug 26 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
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/
Aug 20 2004
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsc14weyl5a2sq9 digitalmars.com...
 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.

I did, old bean. About an hour ago. Assuming that D does indeed pack arrays of bool/bit 8 to a byte, then my example is pretty clear.
Aug 20 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Sat, 21 Aug 2004 11:03:23 +1000, Matthew <admin.hat stlsoft.dot.org> 
wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message 
 news:opsc14weyl5a2sq9 digitalmars.com...
 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 


 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

 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.

I did, old bean. About an hour ago.

I know, my eyes must be broken.
 Assuming that D does indeed pack arrays of bool/bit 8 to a byte, then my 
 example is pretty clear.

I might still be a bit fuzzy on it.. It's the structures binary layout you're concerned with right? Doesn't D have some struct padding specifiers? Does extern C change the way it pads structs? Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 20 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
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.

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/
Aug 20 2004
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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/

Aug 20 2004
parent Regan Heath <regan netwin.co.nz> writes:
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/
Aug 20 2004
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"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/

Aug 20 2004
next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Aug 20 2004
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
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


 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


 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


 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

Aug 20 2004
parent reply Sean Kelly <sean f4.ca> writes:
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
Aug 20 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"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.
Aug 20 2004
prev sibling parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"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


 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


 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


 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.
Aug 20 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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

 be - and bear in mind that bool in C and bool in D are quite different

 implementation dependent!!) - we're still in stuck a bad dream. Now we've

 addressed, the other cannot - of the *same* type *within* a single D

 IMO, it's all just too damn hideous to contemplate. Imagine explaining all

 C++ but heard that D was C++ without all the scary bits and so wanted to

 bit is a wart, and should be abandoned entirely, in favour of bit fields

 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.
Aug 20 2004
next sibling parent reply "antiAlias" <fu bar.com> writes:
I think part of the problem here is that the compiler will not point out the
distinction for you. It's pretty easy for such things to get completely lost
within a sea of C structs, so it makes porting rather more tricky than it
might otherwise be ... for this reason alone, I'd tend to agree with the
suggestion that bool should really be an alias for ubyte.

But, let's not start that all over again :-)


"Walter" <newshound digitalmars.com> wrote in message
news:cg6j0a$17p6$1 digitaldaemon.com...
 "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

 be - and bear in mind that bool in C and bool in D are quite different

 implementation dependent!!) - we're still in stuck a bad dream. Now


 got *different*-semantic flavours - one can be
 addressed, the other cannot - of the *same* type *within* a single D

 IMO, it's all just too damn hideous to contemplate. Imagine explaining


 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

 bit is a wart, and should be abandoned entirely, in favour of bit fields

 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

 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.

Aug 20 2004
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <cg6jbf$186k$1 digitaldaemon.com>, antiAlias says...
I think part of the problem here is that the compiler will not point out the
distinction for you. It's pretty easy for such things to get completely lost
within a sea of C structs, so it makes porting rather more tricky than it
might otherwise be ... for this reason alone, I'd tend to agree with the
suggestion that bool should really be an alias for ubyte.

Same here. Or just toss bool altogether and let people define it as needed. But then I have a feeling we're in the minority on this issue :) Sean
Aug 20 2004
parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <cg6kbc$191v$1 digitaldaemon.com>, Sean Kelly says...

bool should really be an alias for ubyte.

Same here. Or just toss bool altogether and let people define it as needed. But then I have a feeling we're in the minority on this issue :)

Sean

A lot of people, myself included, would prefer that bool were a type logically distinct from either bit or any kind of int, not implicitly intercastable with those types. We would prefer that true and false were values of type bool, not aliases for 1 and 0. So yes - the alias of bool to bit is annoying. But Walter wants it that way, and we've done /so/ much arguing about it in the past. Arcane Jill
Aug 21 2004
prev sibling next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"antiAlias" <fu bar.com> wrote in message
news:cg6jbf$186k$1 digitaldaemon.com...
 I think part of the problem here is that the compiler will not point out the
 distinction for you. It's pretty easy for such things to get completely lost
 within a sea of C structs, so it makes porting rather more tricky than it
 might otherwise be ... for this reason alone, I'd tend to agree with the
 suggestion that bool should really be an alias for ubyte.

 But, let's not start that all over again :-)

Well, although we could go there, this actually has very little to do with most of the bool issues. (I've long since given up hope on that one, partly because I can see some of the various sides on it.) What we're talking about now is pure unadulterated wart. Where's the debate? Just for folks who (like me) can't be arsed to plough through the tall trees of ng debate, I'll rephrase here, pictorially: Version 1 struct X { bool b; // 1-bit, "occupying" 1-byte int x; // 32-bits }; | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | b .............................. .................................... .................................... .................................... x----------------------- ----------------------- ----------------------- ----------------------x When expressed in C, this will look like: struct X { bool b; // 1-bit, "occupying" 1-byte int x; // 32-bits }; All fine so far. (As long as C doesn't use any values other than 0 and 1 for its "bool" type.) Now for the fan-hitting shit. Version 2 struct X { bool b[2]; // 2-bits, "occupying" 1-byte int x; // 32-bits }; | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | b0 b1 ......................... // actually b[0] and b[1], but am short on space .................................... .................................... .................................... x----------------------- ----------------------- ----------------------- ----------------------x When expressed in C, this will look like: struct X { ?????? int x; }; I've written ?????? since there's _no way_ to express bits as an array in C. Of course, we can use a bitfield, as in struct X { bool b0 : 1; bool b1 : 1; int x; }; That form is correct and compatible, but now we're not dealing with an array. Imagine trying to write code to _use_ such a structure's bit-"array" in C. Nasty. But while that's is hopelessly inconvenient in practice, it's perhaps not quite overwhelming. Where we go beyond tolerance is the fact that people will reasonably perceive the equivalent structure in C exactly as it is expressed in D, as in: struct X { bool b[2]; // <Emergency. Emergency. There's an emergency here!> int x; // 32-bits }; All looks peachy, until we look how it's layed out in memory: | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | b[0] ............................ b[1] ............................ .................................... .................................... x----------------------- ----------------------- ----------------------- ----------------------x Now, someone, anyone, please try and convince me that this is not a terrible wart. I'll eat my hat if you succeed. Maybe we don't care about C compatibility. Maybe we're not interested in having D be _dramatically_ easier to interface to than .NET and Java. Maybe we're not interested in D righting the wrongs of C and C++. Maybe we're not concerned that, without *massive* corporate backing, D needs to minimise its exposure to being rightly piloried by people who want to be able to find glaring faults with the briefest exposure. If so, let me know, 'cos I've been working hard (for two years) under a grand delusion and I clearly need to wake up. Winthrop Overthetop
 "Walter" <newshound digitalmars.com> wrote in message
 news:cg6j0a$17p6$1 digitaldaemon.com...
 "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

 be - and bear in mind that bool in C and bool in D are quite different

 implementation dependent!!) - we're still in stuck a bad dream. Now


 got *different*-semantic flavours - one can be
 addressed, the other cannot - of the *same* type *within* a single D

 IMO, it's all just too damn hideous to contemplate. Imagine explaining


 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

 bit is a wart, and should be abandoned entirely, in favour of bit fields

 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

 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.


Aug 20 2004
next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Matthew wrote:

 What we're talking about now is pure unadulterated wart. Where's the debate?
 
 Just for folks who (like me) can't be arsed to plough through the tall trees
of ng debate, I'll rephrase here,
 pictorially:
 
 [Pictoral rephrasing]
 
 Now, someone, anyone, please try and convince me that this is not a terrible
wart. I'll eat my hat if you succeed.
 
 Maybe we don't care about C compatibility. Maybe we're not interested in
having D be _dramatically_ easier to interface
 to than .NET and Java. Maybe we're not interested in D righting the wrongs of
C and C++. Maybe we're not concerned that,
 without *massive* corporate backing, D needs to minimise its exposure to being
rightly piloried by people who want to be
 able to find glaring faults with the briefest exposure. If so, let me know,
'cos I've been working hard (for two years)
 under a grand delusion and I clearly need to wake up.

Yes. It's pretty clear now that bit causes all manner of oddness. Further, a templatized struct would be very easy to write, and could offer nearly, if not completely identical syntax. Overloaded operators and templates were missing from the original spec, as I understand it. From this perspective, a builtin bitset type makes perfect sense. Now, though, keeping it around doesn't seem to offer any compelling benefit at all. Why /not/ dump it? -- andy
Aug 20 2004
parent reply "antiAlias" <fu bar.com> writes:
"Andy Friesen"  wrote
 It's pretty clear now that bit causes all manner of oddness.  Further, a
 templatized struct would be very easy to write, and could offer nearly,
 if not completely identical syntax.

 Overloaded operators and templates were missing from the original spec,
 as I understand it.  From this perspective, a builtin bitset type makes
 perfect sense.  Now, though, keeping it around doesn't seem to offer any
 compelling benefit at all.

 Why /not/ dump it?

Same could be said for AA, also. It's not unusual for large, long-term developments to do some occasional "house-keeping". IMO, that would be a good thing to do before general release.
Aug 20 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"antiAlias" <fu bar.com> wrote in message
news:cg6nrq$1bbr$1 digitaldaemon.com...
 "Andy Friesen"  wrote
 It's pretty clear now that bit causes all manner of oddness.  Further, a
 templatized struct would be very easy to write, and could offer nearly,
 if not completely identical syntax.

 Overloaded operators and templates were missing from the original spec,
 as I understand it.  From this perspective, a builtin bitset type makes
 perfect sense.  Now, though, keeping it around doesn't seem to offer any
 compelling benefit at all.

 Why /not/ dump it?

Same could be said for AA, also. It's not unusual for large, long-term developments to do some occasional "house-keeping". IMO, that would be a good thing to do before general release.

Agreed. I believe there are some serious questions re AAs. But for the moment I'm interested to learn the degree to which my views on bit diverge from the D quorum.
Aug 20 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:cg6l0t$19ii$1 digitaldaemon.com...
 Now, someone, anyone, please try and convince me that this is not a

 Maybe we don't care about C compatibility. Maybe we're not interested in

 to than .NET and Java. Maybe we're not interested in D righting the wrongs

 without *massive* corporate backing, D needs to minimise its exposure to

 able to find glaring faults with the briefest exposure. If so, let me

 under a grand delusion and I clearly need to wake up.

I see, you're trying to access D from C. I really have not anticipated much need for that, but have focussed on making C accessible from D. Not all D types are accessible from C, so if you're writing a D struct to be accessed from C, you'll need to stick with types accessible from C.
Aug 21 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cg848c$28t3$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
 news:cg6l0t$19ii$1 digitaldaemon.com...
 Now, someone, anyone, please try and convince me that this is not a

 Maybe we don't care about C compatibility. Maybe we're not interested in

 to than .NET and Java. Maybe we're not interested in D righting the wrongs

 without *massive* corporate backing, D needs to minimise its exposure to

 able to find glaring faults with the briefest exposure. If so, let me

 under a grand delusion and I clearly need to wake up.

I see, you're trying to access D from C. I really have not anticipated much need for that, but have focussed on making C accessible from D.

I wasn't necessarily assuming any particular direction, though they'll both have to be taken into account.
 Not all D
 types are accessible from C, so if you're writing a D struct to be accessed
 from C, you'll need to stick with types accessible from C.

Which takes me back to my earlier point that bit should be banned from structs and unions.
Aug 21 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cg8bhk$2ctl$1 digitaldaemon.com>, Matthew says...

Which takes me back to my earlier point that bit should be banned from structs
and unions.

I don't like the idea that we would be /forbidden/ from using bits in structs, just in case we might want to pass that struct to a C function, or port the code to C, or whatever. What if we /don't/ want to do any of those things? Should we also forbid complex numbers in structs? Or classes? Or associative arrays? Or, indeed, /anything/ that D has which C doesn't? Jill
Aug 21 2004
parent "Matthew" <admin.hat stlsoft.dot.org> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cg9g21$22i$1 digitaldaemon.com...
 In article <cg8bhk$2ctl$1 digitaldaemon.com>, Matthew says...

Which takes me back to my earlier point that bit should be banned from structs
and unions.

I don't like the idea that we would be /forbidden/ from using bits in structs, just in case we might want to pass that struct to a C function, or port the code to C, or whatever. What if we /don't/ want to do any of those things? Should we also forbid complex numbers in structs? Or classes? Or associative arrays? Or, indeed, /anything/ that D has which C doesn't?

Of course. (& don't forget unions as well) And if that brings out a howl of protest, then I suggest that we need another aggregate class-key for what we now know as struct, since clearly we need something that is unambiguously useful and free of evil subtle pitfalls for interfacing with C. That is, after all, supposedly one of D's major plusses over other C++ evolutions! You might counter that we are able to include non-POD types in structs in C++. There are several responses:P 1. C++ does not have an ABI. Kind of a strange argument, I grant you, but basically without an ABI there's an "excuse" for allowing this inconsistency. 2. C++ has a pre-processor, such that one can conditionally define C++ aspects of a struct (e.g. static members, ctors, etc.), without upsetting the equivalence of size from one language to the other. 3. <stealing myself against the inevitable abuse> C++ practitioners are going to be more able to handle issues of complexity. 4. So what? D doesn't take on other mistakes in C++'s design. 5. C++ has a shared inclusion model, and shares fundamental types and their sizes, between C and C++. My "heat" on this issue is primarily driven by the fact that identical looking structs in C and D can have radically different structures (and this is *not* simply an issue of packing).
Aug 22 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"antiAlias" <fu bar.com> wrote in message
news:cg6jbf$186k$1 digitaldaemon.com...
 I think part of the problem here is that the compiler will not point out

 distinction for you. It's pretty easy for such things to get completely

 within a sea of C structs, so it makes porting rather more tricky than it
 might otherwise be ... for this reason alone, I'd tend to agree with the
 suggestion that bool should really be an alias for ubyte.

 But, let's not start that all over again :-)

Please nooooo <g> I'll admit, though, that the implementation of bit has turned out to be more problematic than I'd originally anticipated, what with things like pointers to bits inside bit arrays, etc.
Aug 21 2004
parent "antiAlias" <fu bar.com> writes:
Yeah ... best laid plans.

Perhaps it could evolve into the 'bitset' idea (a la Delphi) that was noted
by Carlos? That would be very useful to have, and no need for pointers to
'bitset' members either <g>

news:cg6dun$145f$1 digitaldaemon.com


"Walter" <newshound digitalmars.com> wrote in message
news:cg83le$28jf$1 digitaldaemon.com...
 "antiAlias" <fu bar.com> wrote in message
 news:cg6jbf$186k$1 digitaldaemon.com...
 I think part of the problem here is that the compiler will not point out

 distinction for you. It's pretty easy for such things to get completely

 within a sea of C structs, so it makes porting rather more tricky than


 might otherwise be ... for this reason alone, I'd tend to agree with the
 suggestion that bool should really be an alias for ubyte.

 But, let's not start that all over again :-)

Please nooooo <g> I'll admit, though, that the implementation of bit has turned out to be

 problematic than I'd originally anticipated, what with things like

 to bits inside bit arrays, etc.

Aug 21 2004
prev sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cg6j0a$17p6$1 digitaldaemon.com...
 "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

 be - and bear in mind that bool in C and bool in D are quite different

 implementation dependent!!) - we're still in stuck a bad dream. Now we've

 addressed, the other cannot - of the *same* type *within* a single D

 IMO, it's all just too damn hideous to contemplate. Imagine explaining all

 C++ but heard that D was C++ without all the scary bits and so wanted to

 bit is a wart, and should be abandoned entirely, in favour of bit fields

 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.

My example showed the evolution of a struct (with the consequent devolution of the hapless cross-linguist's appreciation of D), wherein the first version _would_ do as you say, but the simple act of turning the single scalar bool in the first version into an array of bool in the second version would result in complete, yet subtle (one might almost say sly), change in structure. I can't fathom why no-one else thinks this stinks worse than the nappy that I was presented with this am. Maybe I'm a fool, or maybe I've misunderstood that the first 9 of the following types all go into a single byte. Please correct me if I'm wrong. 1. bool - in one byte. Correct? 2. bool[1] - in one byte. Correct? 3. bool[2] - in one byte. Correct? 4. bool[3] - in one byte. Correct? 5. bool[4] - in one byte. Correct? 6. bool[5] - in one byte. Correct? 7. bool[6] - in one byte. Correct? 8. bool[7] - in one byte. Correct? 9. bool[8] - in one byte. Correct? 10. bool[9] - in two bytes. Correct? If this is correct, then bit stinks, and should be, at minimum, banned from being used in structs and unions. QED.
Aug 20 2004
parent Ben Hinkle <bhinkle4 juno.com> writes:
Matthew wrote:

 
 "Walter" <newshound digitalmars.com> wrote in message
 news:cg6j0a$17p6$1 digitaldaemon.com...
 "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

 be - and bear in mind that bool in C and bool in D are quite different

 implementation dependent!!) - we're still in stuck a bad dream. Now
 we've

 addressed, the other cannot - of the *same* type *within* a single D

 IMO, it's all just too damn hideous to contemplate. Imagine explaining
 all

 C++ but heard that D was C++ without all the scary bits and so wanted
 to

 bit is a wart, and should be abandoned entirely, in favour of bit
 fields

 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.

My example showed the evolution of a struct (with the consequent devolution of the hapless cross-linguist's appreciation of D), wherein the first version _would_ do as you say, but the simple act of turning the single scalar bool in the first version into an array of bool in the second version would result in complete, yet subtle (one might almost say sly), change in structure. I can't fathom why no-one else thinks this stinks worse than the nappy that I was presented with this am. Maybe I'm a fool, or maybe I've misunderstood that the first 9 of the following types all go into a single byte. Please correct me if I'm wrong. 1. bool - in one byte. Correct? 2. bool[1] - in one byte. Correct? 3. bool[2] - in one byte. Correct? 4. bool[3] - in one byte. Correct? 5. bool[4] - in one byte. Correct? 6. bool[5] - in one byte. Correct? 7. bool[6] - in one byte. Correct? 8. bool[7] - in one byte. Correct? 9. bool[8] - in one byte. Correct? 10. bool[9] - in two bytes. Correct? If this is correct, then bit stinks, and should be, at minimum, banned from being used in structs and unions. QED.

I like the fact that bit is packed when in arrays. If I want unpacked bytes then I'll declare something as an array of bytes. I don't see why using bit arrays in structs should be any different than using them elsewhere. Is it the fact that D and C++ are different that is bothersome? I don't get the problem.
Aug 21 2004
prev sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"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
Aug 20 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:cg6e09$1462$1 digitaldaemon.com...
 However it compiled before. I don't see why it shouldn't now.

That's why 0.100 came out.
Aug 21 2004
parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Walter" <newshound digitalmars.com> escribió en el mensaje
news:cg848e$28t3$3 digitaldaemon.com
| "Carlos Santander B." <carlos8294 msn.com> wrote in message
| news:cg6e09$1462$1 digitaldaemon.com...
|| However it compiled before. I don't see why it shouldn't now.
|
| That's why 0.100 came out.

Thanks for that.

-----------------------
Carlos Santander Bernal
Aug 21 2004