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

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;
}



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 




 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.


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.

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:





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




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:





 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




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:





 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


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


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


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


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.


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


 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.


 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


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


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


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


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


 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.


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


 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.


 
 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