www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - const and mutable declarations in one union

reply Sergey Kovrov <kovrov+digitalmars gmail.com> writes:
Consider following definition:

|class Node
|{
|    union
|    {
|        protected Rect _rect;
|        const struct
|        {
|            short x, y;
|            ushort width, height;
|        }
|    }
|    setRect(...) { ... }
|}

The point is to have a readonly view of data (x, y, width, height), 
protected mutable view of same data (_rect), and an interface to set it 
publicly (setRect).

1. Is this declaration is legal? (const and mutable definitions in one 
union)
2. Is there a difference between const and invariant struct? (I guess it 
should)

The current implementation seems yielding undefined behavior in this 
case. If I set initial const values in constructor everything works as 
expected. If I set initial const values in definition, the whole union 
seems to be immutable, eg. setting ``_rect`` do not have an effect.


-- serg.
Jan 13 2009
parent reply BCS <ao pathlink.com> writes:
Reply to Sergey,


 Consider following definition:
 
 |class Node
 |{
 |    union
 |    {
 |        protected Rect _rect;
 |        const struct
 |        {
 |            short x, y;
 |            ushort width, height;
 |        }
 |    }
 |    setRect(...) { ... }
 |}
 The point is to have a readonly view of data (x, y, width, height),
 protected mutable view of same data (_rect), and an interface to set
 it publicly (setRect).
 
 1. Is this declaration is legal? (const and mutable definitions in one
 union)
 2. Is there a difference between const and invariant struct? (I guess
 it


cost = "you can't chnage it"
invariant = "Will not change at all"


 should)
 The current implementation seems yielding undefined behavior in this
 case. If I set initial const values in constructor everything works as
 expected. If I set initial const values in definition, the whole union
 seems to be immutable, eg. setting ``_rect`` do not have an effect.
 


Setting it in a decleration my put it in read only memeory or even hard code 
it into expressions
Jan 13 2009
parent reply Sergey Kovrov <kovrov+digitalmars gmail.com> writes:
On 1/14/2009 2:18 AM, BCS wrote:

 cost = "you can't chnage it"
 invariant = "Will not change at all"


...

 Setting it in a decleration my put it in read only memeory or even hard
 code it into expressions


Well this is usually oblivious, but not in case of union. Which might be 
a little bit different.. I have an impression that invariant may put 
data to readonly section, but not const.

This of course might be just an invalid usage of union from programmer's 
side, which righteously yeld undefined behavior. but I was hoping for a 
special treat of const (not invariant) in context of union.


-- serg.
Jan 13 2009
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
Sergey Kovrov wrote:

 On 1/14/2009 2:18 AM, BCS wrote:

 cost = "you can't chnage it"
 invariant = "Will not change at all"


 ....

 Setting it in a decleration my put it in read only memeory or even hard
 code it into expressions


 
 Well this is usually oblivious, but not in case of union. Which might be
 a little bit different.. I have an impression that invariant may put
 data to readonly section, but not const.
 
 This of course might be just an invalid usage of union from programmer's
 side, which righteously yeld undefined behavior. but I was hoping for a
 special treat of const (not invariant) in context of union.
 
 
 -- serg.


Yeah, if this doesn't cause compilation to fail, I'm pretty sure it
should.  You're giving the compiler two contradictory statements
regarding the mutability of that data.

Rather, why not use this?


 class Node
 {
     protected Rect _rect;

     short x() { return _rect.x; }
     short y() { return _rect.y; }
     ushort width() { return _rect.width; }
     ushort height() { return _rect.height; }

     setRect(...) { ... }
 }


This will have more or less the same outward-facing interface, whilst
actually working.

Incidentally, I've haven't used opDot before, but this might also work:


 class Node
 {
     protected Rect _rect;

     const Rect* opDot() { return &_rect; }

     setRect(...) { ... }
 }


Finally, if you have questions on how to do something, please direct
them to the D.learn newsgroup in future.

  -- Daniel
Jan 13 2009
parent Sergey Kovrov <kovrov+digitalmars gmail.com> writes:
On 1/14/2009 3:18 AM, Daniel Keep wrote:

 Finally, if you have questions on how to do something, please direct
 them to the D.learn newsgroup in future.


Well, this was not exactly point of my question - how to do this. There 
are few "valid" ways - getters/setters (properties) is one of them, to 
have const pointers to mutable data is other, and perhaps there could be 
even more.

I just wanted to point if such usage of union is invalid, it will be 
nice to assert this in compile time or at least have note in specs.

Or rather I wanted to comment on using invariant and const in this 
context lead to same effect - immutable declaration, which is feels 
wrong. If I were used invariant - this would be exactly what I expect. 
But for const I hope to get readonly view of any data, be it immutable 
or not.


-- serg.
Jan 13 2009