www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - symbol aliasing in structs

reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Not sure if this is a bug,
this works:

#struct Fields
#{
#	bit[32] b;
#	alias b field;
#}

but this doesnt:


#struct Fields
#{
#	bit[32] b;
#	alias b[0] field;
#}

produces error messege:
C:\test\d>dmd bits.d
bits.d(6): b is used as a type

on dmd 0.137

I guess it parsed that as: field is an alias for an array of zero b's. 
woops, type b is not defined!

According to the docs, the compiler should be smart enough to actually 
figure out whether b is a type or a symbol.

Quote from http://www.digitalmars.com/d/declaration.html

Note: Type aliases can sometimes look indistinguishable from alias 

#alias foo.bar abc;	// is it a type or a symbol?
The distinction is made in the semantic analysis pass.

Nov 07 2005
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 07 Nov 2005 02:10:35 -0700, Hasan Aljudy <hasan.aljudy gmail.com>  
wrote:
 Not sure if this is a bug,
 this works:

 #struct Fields
 #{
 #	bit[32] b;
 #	alias b field;
 #}

 but this doesnt:


 #struct Fields
 #{
 #	bit[32] b;
 #	alias b[0] field;
 #}

 produces error messege:
 C:\test\d>dmd bits.d
 bits.d(6): b is used as a type

 on dmd 0.137

 I guess it parsed that as: field is an alias for an array of zero b's.  
 woops, type b is not defined!

Ahh! So that is what it was doing. I never did figure it out. I would _love_ for this to work. Regan
Nov 07 2005
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message
news:dkn5mb$2aq9$1 digitaldaemon.com...
 Not sure if this is a bug,
 this works:

 #struct Fields
 #{
 # bit[32] b;
 # alias b field;
 #}

 but this doesnt:


 #struct Fields
 #{
 # bit[32] b;
 # alias b[0] field;
 #}

I'm not sure what is intended here, but b isn't a type, and one can only create an alias for a type or a symbol. b[0] is neither, hence an error message. I don't think this is a compiler bug.
Nov 07 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 7 Nov 2005 22:14:45 -0800, Walter Bright wrote:

 "Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message
 news:dkn5mb$2aq9$1 digitaldaemon.com...
 Not sure if this is a bug,
 this works:

 #struct Fields
 #{
 # bit[32] b;
 # alias b field;
 #}

 but this doesnt:


 #struct Fields
 #{
 # bit[32] b;
 # alias b[0] field;
 #}

I'm not sure what is intended here,

I thought it was obvious what was intended. Namely that "field" is a shorthand way of referring to "b[0]"; an alias, if you like.
but b isn't a type, and one can only
 create an alias for a type or a symbol. 
b[0] is neither, hence an error
 message. I don't think this is a compiler bug.

Fair enough comment. What is the preferred way of referencing individual bits in a platform agnostic manner? If I have a piece of RAM that is 8 bits long, is there some way I can name the bit-fields mapped over that block of RAM? My simplistic attempt has failed big time. struct Fields { bit fldA; bit fldB; bit[4] fldC; bit fldD; bit fldE; } This coding above doesn't seem to map to the 8 bits of my block of RAM. By that I mean that the bit with the lowest address (ie. the address of the 8-bit long block of RAM) is the first bit and is called fldA, the next adjacent bit to the right (higher *bit* address) if fldB, then next four bits is a single field called fldC (values 0 to 15), the next adjacent bit is fldD, and the last bit in the RAM block is fldE. However, I can't seem to set them or get them correctly and the size of the struct is not 1 (one) as I'd expect. void main() { Fields q; q.fldA = 0; q.fldB = 1; q.fldC[] = 1; q.fldD = 0; q.fldE = 1; writefln("%x %d", *(cast(byte*)(&(q))), q.sizeof); } This compiles and prints "0 8" but I expected "7d 1" -- Derek (skype: derek.j.parnell) Melbourne, Australia 8/11/2005 5:36:07 PM
Nov 07 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1tud7p1r6ehw8.sfqxfg7qd4rz$.dlg 40tude.net...
 What is the preferred way of referencing individual bits in a platform
 agnostic manner? If I have a piece of RAM that is 8 bits long, is there
 some way I can name the bit-fields mapped over that block of RAM? My
 simplistic attempt has failed big time.

Klunky, but this'll work: struct Fields { bit foo[8]; bit fldA() { return foo[0]; } bit fldA(bit s) { return foo[0] = s; } ... etc ... }
Nov 08 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Tue, 8 Nov 2005 01:02:07 -0800, Walter Bright wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:1tud7p1r6ehw8.sfqxfg7qd4rz$.dlg 40tude.net...
 What is the preferred way of referencing individual bits in a platform
 agnostic manner? If I have a piece of RAM that is 8 bits long, is there
 some way I can name the bit-fields mapped over that block of RAM? My
 simplistic attempt has failed big time.

Klunky, but this'll work: struct Fields { bit foo[8]; bit fldA() { return foo[0]; } bit fldA(bit s) { return foo[0] = s; } ... etc ... }

Yuck! Can't you do better? Anyhow, would I have to worry about endian-ness with this 'technique'? In other words, does foo[0] always reference the bit with the lowest RAM address? -- Derek Parnell Melbourne, Australia 8/11/2005 11:17:08 PM
Nov 08 2005
parent "Walter Bright" <newshound digitalmars.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:1tz7dpeylfsl0$.1ry62433jeiwu$.dlg 40tude.net...
 On Tue, 8 Nov 2005 01:02:07 -0800, Walter Bright wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:1tud7p1r6ehw8.sfqxfg7qd4rz$.dlg 40tude.net...
 What is the preferred way of referencing individual bits in a platform
 agnostic manner? If I have a piece of RAM that is 8 bits long, is there
 some way I can name the bit-fields mapped over that block of RAM? My
 simplistic attempt has failed big time.

Klunky, but this'll work: struct Fields { bit foo[8]; bit fldA() { return foo[0]; } bit fldA(bit s) { return foo[0] = s; } ... etc ... }

Yuck! Can't you do better? Anyhow, would I have to worry about endian-ness with this 'technique'? In other words, does foo[0] always reference the

 with the lowest RAM address?

It always references the bit with the lowest bit address in the byte, and the lowest byte address in ram.
Nov 08 2005
prev sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 "Derek Parnell" <derek psych.ward> wrote in message
 news:1tud7p1r6ehw8.sfqxfg7qd4rz$.dlg 40tude.net...
 
What is the preferred way of referencing individual bits in a platform
agnostic manner? If I have a piece of RAM that is 8 bits long, is there
some way I can name the bit-fields mapped over that block of RAM? My
simplistic attempt has failed big time.

Klunky, but this'll work: struct Fields { bit foo[8]; bit fldA() { return foo[0]; } bit fldA(bit s) { return foo[0] = s; } ... etc ... }

Wouldn't return by reference simplify these cases where property doesn't need to do any real task except get or set? Something like: inout bit fldA() { return foo[0]; } Is there any chance for this ever to be in D?
Nov 08 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
news:dkqgot$2jhf$1 digitaldaemon.com...
 Wouldn't return by reference simplify these cases where property doesn't
 need to do any real task except get or set?
 Something like:
 inout bit fldA() { return foo[0]; }

 Is there any chance for this ever to be in D?

Doing references to bits will require more than just a pointer, it'll have to be a pointer plus a bit number. Then, these won't work like regular pointers. There really isn't a good solution, it's just an issue of where are the seams going to trip you.
Nov 08 2005
next sibling parent Georg Wrede <georg.wrede nospam.org> writes:
Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
 news:dkqgot$2jhf$1 digitaldaemon.com...
 
Wouldn't return by reference simplify these cases where property doesn't
need to do any real task except get or set?
Something like:
inout bit fldA() { return foo[0]; }

Is there any chance for this ever to be in D?

Doing references to bits will require more than just a pointer, it'll have to be a pointer plus a bit number. Then, these won't work like regular pointers. There really isn't a good solution, it's just an issue of where are the seams going to trip you.

<flame on> At risk of sounding like a bitching old lady: So even here the bit datatype is not _genuinely_ supported by the language! Either this kind of things should work uniformly with the other integral datatypes (syntactically, that is), or we should consider skipping bit as a separate data type altogether. This would save us from a lot of pretense, and it would let the specification be changed to "bool is implemented internally as the fastest or most convenient integer type, but cast to or from bool is implicitly rewritten as return (value == 0) ? 0 : 1; By this time D is _sexy_ enough to not anymore need such arcane marketing pranks as "bit datatype". Also, even this discussion should serve as an example of the confusion and frustration and misunderstanding and unwarranted hopes, that this pretense fosters. <grrrrr>
Nov 09 2005
prev sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
 news:dkqgot$2jhf$1 digitaldaemon.com...
 
Wouldn't return by reference simplify these cases where property doesn't
need to do any real task except get or set?
Something like:
inout bit fldA() { return foo[0]; }

Is there any chance for this ever to be in D?

Doing references to bits will require more than just a pointer, it'll have to be a pointer plus a bit number.

Why not?
 Then, these won't work like regular pointers. 

So what? Pointers to bits are not regular pointers and trying to classify them as pointers is wrong. I like the idea of bit type and find that it could be usefull, but as it is now to many things can not be done with them. I wouldn't have anything against bit* being 2*size_t, plus some rules of casting bit* to normal pointers.
 There really isn't a good solution, it's just an issue of where
 are the seams going to trip you.
 

I didn't understand this part, but i have to say i wasn't trying to start a bit-war, i was just thinking and trying to say how returning refereces would be a really nice feature. It is probably the *only* thing i miss from C++.
Nov 09 2005
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
news:dksr7t$t4b$1 digitaldaemon.com...
 Walter Bright wrote:
 Doing references to bits will require more than just a pointer, it'll


 to be a pointer plus a bit number.

 Then, these won't work like regular pointers.

So what? Pointers to bits are not regular pointers and trying to classify them as pointers is wrong.

I guarantee that, if implemented, there will be issues because it can't be converted back and forth between void*.
Nov 09 2005
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 "Ivan Senji" <ivan.senji_REMOVE_ _THIS__gmail.com> wrote in message
 news:dksr7t$t4b$1 digitaldaemon.com...
 
Walter Bright wrote:
Then, these won't work like regular pointers.

So what? Pointers to bits are not regular pointers and trying to classify them as pointers is wrong.

I guarantee that, if implemented, there will be issues because it can't be converted back and forth between void*.

Yes, but you can call a well documented issue a feature :) bit[8] bits; //located on adress 0xABCDEFGH bit* bitptr = &bit[1]; // bitptr == {0xABCDEFGH, 1}; void* voidptr = cast(void*)bitptr; //voidptr = {0xABCDEFGH} bitptr* = cast(bit*)voidptr; //bitptr == {0xABCDEFGH, 0}; And it doesn't feel souch a big issue.
Nov 09 2005
prev sibling next sibling parent Florian Sonnenberger <nairolf online.de> writes:
Walter Bright schrieb:
 I'm not sure what is intended here, but b isn't a type, and one can only
 create an alias for a type or a symbol. (...)
 

But properties are symbols, right? So, why does this code not compile: struct foo { int[] bar; alias bar.length size; } ----- foobar.d(19): no property 'length' for type 'int[]' foobar.d(19): bar.length is used as a type ----- This also happens with .sizeof, .min, .max, .alignof, .dup, .init, ... (I already posted this in digitalmars.D.bugs/5301 ) Thanks, Florian
Nov 08 2005
prev sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Walter Bright wrote:
 "Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message
 news:dkn5mb$2aq9$1 digitaldaemon.com...
 
Not sure if this is a bug,
this works:

#struct Fields
#{
# bit[32] b;
# alias b field;
#}

but this doesnt:


#struct Fields
#{
# bit[32] b;
# alias b[0] field;
#}

I'm not sure what is intended here, but b isn't a type, and one can only create an alias for a type or a symbol. b[0] is neither, hence an error message. I don't think this is a compiler bug.

Fair enough. I wasn't clear on what "symbol" means (I think I'm still not clear on it). I thought that "symbol" just means "variable".
Nov 08 2005