www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: bit fields in structs

reply Arcane Jill <Arcane_member pathlink.com> writes:
Moving this here for general discussion, as I don't think it's a bug report any
more.

In article <cg9h3o$43o$1 digitaldaemon.com>, Matthew says...
"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).

What about an extra keyword like "strict" or something, which disallows anything which is not a POD? I confess I don't like the idea of completely disallowing non-PODs in all structs. A while back, some folk were suggesting that I implement my class Int as a struct, because it had copy semantics. There were reasons why I didn't do that, but, if I had, that struct would have been disallowed under your last suggestion. On the other hand, a struct specially marked as a POD would presumably keep you happy as well as I? Besides, "strict struct" sounds kinda poetic. Arcane Jill
Aug 22 2004
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Arcane Jill" <Arcane_member pathlink.com> wrote in message
news:cg9p04$9p6$1 digitaldaemon.com...
 Moving this here for general discussion, as I don't think it's a bug report any
 more.

 In article <cg9h3o$43o$1 digitaldaemon.com>, Matthew says...
"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


as struct, since clearly we need something that is unambiguously useful and
free of evil subtle pitfalls for


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


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,


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


issue is primarily driven by the fact that identical looking structs in C and D
can have radically different


(and this is *not* simply an issue of packing).

What about an extra keyword like "strict" or something, which disallows anything which is not a POD? I confess I don't like the idea of completely disallowing non-PODs in all structs. A while back, some folk were suggesting that I implement my class Int as a struct, because it had copy semantics. There were reasons why I didn't do that, but, if I had, that struct would have been disallowed under your last suggestion. On the other hand, a struct specially marked as a POD would presumably keep you happy as well as I? Besides, "strict struct" sounds kinda poetic.

Nope, too easy to abuse. The smart answer is to think of another class key for what we call struct. We have the following types of things: - unions - C-compatible structs - "D" structs - classes To my mind, mixing "D" structs and C-compatible structs has always been a very odd idea, and, in light of what we've realised about bit members/bitfields over the last couple of days, I now consider it completely broken. "D" structs are a weird thing to call struct, and we should leave struct to what the rest of the world knows it as. I'm sure one of the myriad geniuses who opine on this group can think of a new class-key for that type of thing. "valclass", "vclass", "val" all such hard, but might inspire some creative soul. Otherwise, we'll just have utter confusion, and well-deserved criticism.
Aug 22 2004
parent reply Ben Hinkle <bhinkle4 juno.com> writes:
Matthew wrote:

 
 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:cg9p04$9p6$1 digitaldaemon.com...
 Moving this here for general discussion, as I don't think it's a bug
 report any more.

 In article <cg9h3o$43o$1 digitaldaemon.com>, Matthew says...
"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


as struct, since clearly we need something that is unambiguously useful
and free of evil subtle pitfalls for


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


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,


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


issue is primarily driven by the fact that identical looking structs in
C and D can have radically different


(and this is *not* simply an issue of packing).

What about an extra keyword like "strict" or something, which disallows anything which is not a POD? I confess I don't like the idea of completely disallowing non-PODs in all structs. A while back, some folk were suggesting that I implement my class Int as a struct, because it had copy semantics. There were reasons why I didn't do that, but, if I had, that struct would have been disallowed under your last suggestion. On the other hand, a struct specially marked as a POD would presumably keep you happy as well as I? Besides, "strict struct" sounds kinda poetic.

Nope, too easy to abuse. The smart answer is to think of another class key for what we call struct. We have the following types of things: - unions - C-compatible structs - "D" structs - classes To my mind, mixing "D" structs and C-compatible structs has always been a very odd idea, and, in light of what we've realised about bit members/bitfields over the last couple of days, I now consider it completely broken. "D" structs are a weird thing to call struct, and we should leave struct to what the rest of the world knows it as. I'm sure one of the myriad geniuses who opine on this group can think of a new class-key for that type of thing. "valclass", "vclass", "val" all such hard, but might inspire some creative soul. Otherwise, we'll just have utter confusion, and well-deserved criticism.

To me the word "struct" suggests a certain semantics (eg, allocated on the stack, copy-by-value, etc). C# uses the word "struct" to declare a data structure with these semantics. C compatibility is orthogonal, much like the size of "int" or "char[]".
Aug 22 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Sun, 22 Aug 2004 08:40:18 -0400, Ben Hinkle <bhinkle4 juno.com> wrote:
 Matthew wrote:

 "Arcane Jill" <Arcane_member pathlink.com> wrote in message
 news:cg9p04$9p6$1 digitaldaemon.com...
 Moving this here for general discussion, as I don't think it's a bug
 report any more.

 In article <cg9h3o$43o$1 digitaldaemon.com>, Matthew says...
"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


 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/ 


 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 


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


as struct, since clearly we need something that is unambiguously 

and free of evil subtle pitfalls for


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


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,


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 

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


issue is primarily driven by the fact that identical looking structs 

C and D can have radically different


(and this is *not* simply an issue of packing).

What about an extra keyword like "strict" or something, which disallows anything which is not a POD? I confess I don't like the idea of completely disallowing non-PODs in all structs. A while back, some folk were suggesting that I implement my class Int as a struct, because it had copy semantics. There were reasons why I didn't do that, but, if I had, that struct would have been disallowed under your last suggestion. On the other hand, a struct specially marked as a POD would presumably keep you happy as well as I? Besides, "strict struct" sounds kinda poetic.

Nope, too easy to abuse. The smart answer is to think of another class key for what we call struct. We have the following types of things: - unions - C-compatible structs - "D" structs - classes To my mind, mixing "D" structs and C-compatible structs has always been a very odd idea, and, in light of what we've realised about bit members/bitfields over the last couple of days, I now consider it completely broken. "D" structs are a weird thing to call struct, and we should leave struct to what the rest of the world knows it as. I'm sure one of the myriad geniuses who opine on this group can think of a new class-key for that type of thing. "valclass", "vclass", "val" all such hard, but might inspire some creative soul. Otherwise, we'll just have utter confusion, and well-deserved criticism.

To me the word "struct" suggests a certain semantics (eg, allocated on the stack, copy-by-value, etc). C# uses the word "struct" to declare a data structure with these semantics. C compatibility is orthogonal, much like the size of "int" or "char[]".

So lets call the D struct a 'memblock' or 'stackblock' or .. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 22 2004
parent reply Tom Sawyer <tsawyer hannible.mo> writes:
On Mon, 23 Aug 2004 10:24:04 +1200, Regan Heath wrote:

 What about an extra keyword like "strict" or something, which disallows
 anything which is not a POD? I confess I don't like the idea of
 completely disallowing non-PODs in all structs. A while back, some folk
 were suggesting that I implement my class Int as a struct, because it 
 had
 copy semantics. There were reasons why I didn't do that, but, if I had,
 that struct would have been disallowed under your last suggestion. On 
 the
 other hand, a struct specially marked as a POD would presumably keep 
 you
 happy as well as I? Besides, "strict struct" sounds kinda poetic.

Nope, too easy to abuse. The smart answer is to think of another class key for what we call struct. We have the following types of things: - unions - C-compatible structs - "D" structs - classes To my mind, mixing "D" structs and C-compatible structs has always been a very odd idea, and, in light of what we've realised about bit members/bitfields over the last couple of days, I now consider it completely broken. "D" structs are a weird thing to call struct, and we should leave struct to what the rest of the world knows it as. I'm sure one of the myriad geniuses who opine on this group can think of a new class-key for that type of thing. "valclass", "vclass", "val" all such hard, but might inspire some creative soul. Otherwise, we'll just have utter confusion, and well-deserved criticism.

To me the word "struct" suggests a certain semantics (eg, allocated on the stack, copy-by-value, etc). C# uses the word "struct" to declare a data structure with these semantics. C compatibility is orthogonal, much like the size of "int" or "char[]".

So lets call the D struct a 'memblock' or 'stackblock' or ..

That doesn't accurately portray what the object is. Think of it this way - we implicitly have structures of any combination of objects we wish already. This is just the range of variables defined at the start of a block of statements or other places. Within the scope of the block, you refer to the member by just using the member name. Outside the scope of the block, you access the member by referring the the name of the block plus the member name. This looks like a structure reference from a programming point of view. So why not make this official? Add a "scope" keyword that then takes any combination of variables or what-not and makes it accessible in the same manner.
Aug 22 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Sun, 22 Aug 2004 21:56:44 -0700, Tom Sawyer <tsawyer hannible.mo> wrote:
 On Mon, 23 Aug 2004 10:24:04 +1200, Regan Heath wrote:

 What about an extra keyword like "strict" or something, which 
 disallows
 anything which is not a POD? I confess I don't like the idea of
 completely disallowing non-PODs in all structs. A while back, some 
 folk
 were suggesting that I implement my class Int as a struct, because it
 had
 copy semantics. There were reasons why I didn't do that, but, if I 
 had,
 that struct would have been disallowed under your last suggestion. On
 the
 other hand, a struct specially marked as a POD would presumably keep
 you
 happy as well as I? Besides, "strict struct" sounds kinda poetic.

Nope, too easy to abuse. The smart answer is to think of another class key for what we call struct. We have the following types of things: - unions - C-compatible structs - "D" structs - classes To my mind, mixing "D" structs and C-compatible structs has always been a very odd idea, and, in light of what we've realised about bit members/bitfields over the last couple of days, I now consider it completely broken. "D" structs are a weird thing to call struct, and we should leave struct to what the rest of the world knows it as. I'm sure one of the myriad geniuses who opine on this group can think of a new class-key for that type of thing. "valclass", "vclass", "val" all such hard, but might inspire some creative soul. Otherwise, we'll just have utter confusion, and well-deserved criticism.

To me the word "struct" suggests a certain semantics (eg, allocated on the stack, copy-by-value, etc). C# uses the word "struct" to declare a data structure with these semantics. C compatibility is orthogonal, much like the size of "int" or "char[]".

So lets call the D struct a 'memblock' or 'stackblock' or ..

That doesn't accurately portray what the object is. Think of it this way - we implicitly have structures of any combination of objects we wish already. This is just the range of variables defined at the start of a block of statements or other places. Within the scope of the block, you refer to the member by just using the member name. Outside the scope of the block, you access the member by referring the the name of the block plus the member name. This looks like a structure reference from a programming point of view. So why not make this official? Add a "scope" keyword that then takes any combination of variables or what-not and makes it accessible in the same manner.

Correct me if I am wrong but A struct differs from a scope in that a struct defines the ordering in memory of it's contained types, a scope doesn't. Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 22 2004
parent reply Tom Sawyer <tsawyer hannible.mo> writes:
On Mon, 23 Aug 2004 17:05:01 +1200, Regan Heath wrote:

 On Sun, 22 Aug 2004 21:56:44 -0700, Tom Sawyer <tsawyer hannible.mo> wrote:

 we implicitly have structures of any combination of objects we wish
 already. This is just the range of variables defined at the start of a
 block of statements or other places. Within the scope of the block, you
 refer to the member by just using the member name. Outside the scope of
 the block, you access the member by referring the the name of the block
 plus the member name. This looks like a structure reference from a
 programming point of view.

 So why not make this official? Add a "scope" keyword that then takes
 any combination of variables or what-not and makes it accessible in the
 same manner.

Correct me if I am wrong but A struct differs from a scope in that a struct defines the ordering in memory of it's contained types, a scope doesn't.

They are different internally, but look much the same from a programming point of view. I was wondering if it wouldn't be too difficult to extend the "looks like" into an actual structural feature. It also doesn't need to be called "scope," that was just a suggestion. It could be called any number of things like "aggregate" or "compound".
Aug 23 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Mon, 23 Aug 2004 14:35:46 -0700, Tom Sawyer <tsawyer hannible.mo> wrote:
 On Mon, 23 Aug 2004 17:05:01 +1200, Regan Heath wrote:

 On Sun, 22 Aug 2004 21:56:44 -0700, Tom Sawyer <tsawyer hannible.mo> 
 wrote:

 we implicitly have structures of any combination of objects we wish
 already. This is just the range of variables defined at the start of a
 block of statements or other places. Within the scope of the block, you
 refer to the member by just using the member name. Outside the scope of
 the block, you access the member by referring the the name of the block
 plus the member name. This looks like a structure reference from a
 programming point of view.

 So why not make this official? Add a "scope" keyword that then takes
 any combination of variables or what-not and makes it accessible in the
 same manner.

Correct me if I am wrong but A struct differs from a scope in that a struct defines the ordering in memory of it's contained types, a scope doesn't.

They are different internally, but look much the same from a programming point of view. I was wondering if it wouldn't be too difficult to extend the "looks like" into an actual structural feature.

They may look similar, but they differ in meaning.. a struct is a declaration of something that might exist at a later time, a scope exists when you see it, i.e. struct a { int a; } means 0 or more of these might exist some time later. if (true) { int a; } means 1 of these exists now (possible more than 1 if the code is threaded). In addition a scope contains inline code, and is created upon entry and destroyed on exit.
 It also doesn't need to be called "scope," that was just a suggestion. It
 could be called any number of things like "aggregate" or "compound".

Those names are better. I don't think we should confuse 'struct' with 'scope' I think they're different concepts. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Aug 23 2004
prev sibling parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <pan.2004.08.23.04.56.43.448847 hannible.mo>, Tom Sawyer says...

we implicitly have structures of any combination of objects we wish
already. This is just the range of variables defined at the start of a
block of statements or other places. Within the scope of the block, you
refer to the member by just using the member name. Outside the scope of
the block, you access the member by referring the the name of the block
plus the member name.

Outside of a statment block, local variables declared within that block /don't exist/. They cannot be reference in any way. Am I missing something? Arcane Jill
Aug 22 2004
parent Tom Sawyer <tsawyer hannible.mo> writes:
On Mon, 23 Aug 2004 05:56:13 +0000, Arcane Jill wrote:

 In article <pan.2004.08.23.04.56.43.448847 hannible.mo>, Tom Sawyer says...
 
we implicitly have structures of any combination of objects we wish
already. This is just the range of variables defined at the start of a
block of statements or other places. Within the scope of the block, you
refer to the member by just using the member name. Outside the scope of
the block, you access the member by referring the the name of the block
plus the member name.

Outside of a statment block, local variables declared within that block /don't exist/. They cannot be reference in any way. Am I missing something?

Static local variables always exist. I'm not sure if they are accessible outside the function as I just recently started working with D, but the certainly exist.
Aug 23 2004