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





but this doesnt:


#struct Fields





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 


declarations:


#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





 but this doesnt:


 #struct Fields





 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





 but this doesnt:


 #struct Fields






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





 but this doesnt:


 #struct Fields






 
 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


bit

 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




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 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 
http://www.digitalmars.com/drn-bin/wwwnews?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





but this doesnt:


#struct Fields






 
 
 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