www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Abnormal struct properties behaviour

reply nail <nail_member pathlink.com> writes:
Hi all.

Consider following situation. We have a struct named Vector3 it has members
public x, y and z. Also we have a class Camera that has property, for example,
eye. The code is something like this:

struct Vector3
{
float x, y, z;
...
}

class Camera
{
protected Vector3 _eye;

public void eye(Vector3 v)
{
_eye = v;
// do something more
}

public Vector3 eye()
{
return _eye;
}
}

void main()
{
Camera cam = new Camera();
cam.eye.y = 5; // dead line
}

In the code above "dead line" leads to changing y of the copy of the eye. I
think this is not desired behaviour. Something must be done to correct this
language behaviour. I don't know what is the best solution, but the following
IMHO should work:
If we write-access members/props of the struct returned by property then for
writing second, write-property, must be called with parameter that is the
changed copy of the read-property. ahem... I think I explain too complicately
:). In another words, in the example above:
1) cam.eye() returns a copy of original vector _eye
2) 'y' component of this copy is changed to 5
3) write-property came.eye(Vector3) must be called with parameter obtained in
previous action.

Comments?
Dec 20 2004
next sibling parent "Lionello Lunesu" <lionello.lunesu crystalinter.remove.com> writes:
Hi.

"nail" <nail_member pathlink.com> wrote in message 
news:cq6h3c$1tj$1 digitaldaemon.com...


 [...]
 public Vector3 eye()
 {
 return _eye;
 }
 }

 void main()
 {
 Camera cam = new Camera();
 cam.eye.y = 5; // dead line
 }

 In the code above "dead line" leads to changing y of the copy of the eye.


Check the other thread in this newsgroup about "inout return values". I 
guess you'd want something like "inout Vector3 eye() { return eye; }" which 
would return a C++-like reference to the struct, instead of a copy.

....This is not yet possible, by the way :-S

L.
Dec 20 2004
prev sibling next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
nail wrote:


 Consider following situation. We have a struct named Vector3 it has members
 public x, y and z. Also we have a class Camera that has property, for example,
 eye. 
 
 In the code above "dead line" leads to changing y of the copy of the eye. I
 think this is not desired behaviour. Something must be done to correct this
 language behaviour.


Until D gets C++-like references, structs won't work for properties...

You need to either make Vector3 a class, or x/y/z into Camera fields ?

--anders
Dec 20 2004
parent reply nail <nail_member pathlink.com> writes:
In article <cq6ivh$3rt$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...

nail wrote:


 Consider following situation. We have a struct named Vector3 it has members
 public x, y and z. Also we have a class Camera that has property, for example,
 eye. 
 
 In the code above "dead line" leads to changing y of the copy of the eye. I
 think this is not desired behaviour. Something must be done to correct this
 language behaviour.


Until D gets C++-like references, structs won't work for properties...


I don't want a reference for eye. I want double call of property setter /
getter. First I get a property, then I change it, then I set property with
additional operations coded in eye(Vector3 v)


You need to either make Vector3 a class, or x/y/z into Camera fields ?


First is impossible because of performance issues. Second is very annoying for
example if I'd have not 3 members but 103.


--anders
Dec 20 2004
parent David Medlock <amedlock nospam.org> writes:
nail wrote:


You need to either make Vector3 a class, or x/y/z into Camera fields ?


 
 
 First is impossible because of performance issues. Second is very annoying for
 example if I'd have not 3 members but 103.
 
 

--anders


 


Have you measured the performance issues?  I am doing exactly this sort 
of coding and I see very small differences in struct/vs class ( at least 
compared to other parts of my code which use up more time).

Typically I have 2 needs for Vectors/Points:
1. Equations such as what you posted, these are typically a minute 
portion of your running time.
2. Groups of them such as 3d Models where large quantities need to be 
manipulated.


handles mass changes to the data and using vertex Arrays easy.

Just my $0.02.
Dec 20 2004
prev sibling next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
nail wrote:


 Hi all.
 
 Consider following situation. We have a struct named Vector3 it has
 members public x, y and z. Also we have a class Camera that has property,
 for example, eye. The code is something like this:
 
 struct Vector3
 {
 float x, y, z;
 ...
 }
 
 class Camera
 {
 protected Vector3 _eye;
 
 public void eye(Vector3 v)
 {
 _eye = v;
 // do something more
 }
 
 public Vector3 eye()
 {
 return _eye;
 }
 }
 
 void main()
 {
 Camera cam = new Camera();
 cam.eye.y = 5; // dead line
 }
 
 In the code above "dead line" leads to changing y of the copy of the eye.
 I think this is not desired behaviour. Something must be done to correct
 this language behaviour. I don't know what is the best solution, but the
 following IMHO should work:
 If we write-access members/props of the struct returned by property then
 for writing second, write-property, must be called with parameter that is
 the changed copy of the read-property. ahem... I think I explain too
 complicately
 :). In another words, in the example above:
 1) cam.eye() returns a copy of original vector _eye
 2) 'y' component of this copy is changed to 5
 3) write-property came.eye(Vector3) must be called with parameter obtained
 in previous action.
 
 Comments?


There are some other options besides making language changes:

1) it seems like you want your class to "do something more" when the entire
eye is set but not when just the y component is set. This seems odd to me
so I assume it is an artifact of shortening the example for posting. So my
first reaction is the current behavior is avoiding a bug in your code.

2) returning a pointer from eye() isn't too bad and makes it obvious it is a
reference. The line cam.eye.y would then change the copy owned by the
Camera. But as I said in 1 this seems like it seems like that opens up a
hole to change _eye without doing something more.

3) add properties to just set or translate one component of eye at a time.
For example
void eyeY(float new_y) { _eye.y = new_y; //do something more }
Then instead of cam.eye.y = 5 you have cam.eyeY = 5.

4) don't do anything and just leave the eye setter as the only way to change
_eye. I don't think users will be confused by the behavior of cam.eye.y = 5

-Ben
Dec 20 2004
parent reply nail <nail_member pathlink.com> writes:
In article <cq6kee$59v$1 digitaldaemon.com>, Ben Hinkle says...

nail wrote:


 Hi all.
 
 Consider following situation. We have a struct named Vector3 it has
 members public x, y and z. Also we have a class Camera that has property,
 for example, eye. The code is something like this:
 
 struct Vector3
 {
 float x, y, z;
 ...
 }
 
 class Camera
 {
 protected Vector3 _eye;
 
 public void eye(Vector3 v)
 {
 _eye = v;
 // do something more
 }
 
 public Vector3 eye()
 {
 return _eye;
 }
 }
 
 void main()
 {
 Camera cam = new Camera();
 cam.eye.y = 5; // dead line
 }
 
 In the code above "dead line" leads to changing y of the copy of the eye.
 I think this is not desired behaviour. Something must be done to correct
 this language behaviour. I don't know what is the best solution, but the
 following IMHO should work:
 If we write-access members/props of the struct returned by property then
 for writing second, write-property, must be called with parameter that is
 the changed copy of the read-property. ahem... I think I explain too
 complicately
 :). In another words, in the example above:
 1) cam.eye() returns a copy of original vector _eye
 2) 'y' component of this copy is changed to 5
 3) write-property came.eye(Vector3) must be called with parameter obtained
 in previous action.
 
 Comments?


There are some other options besides making language changes:

1) it seems like you want your class to "do something more" when the entire
eye is set but not when just the y component is set. This seems odd to me
so I assume it is an artifact of shortening the example for posting. So my
first reaction is the current behavior is avoiding a bug in your code.


"do something more" hides the following, for example:
renderSystem.SetViewMatrix( Matrix44.lookAt(_eye, _target, _up) );
you can see that it is necessary to be called even if one component changed.


2) returning a pointer from eye() isn't too bad and makes it obvious it is a
reference. The line cam.eye.y would then change the copy owned by the
Camera. But as I said in 1 this seems like it seems like that opens up a
hole to change _eye without doing something more.


in this case additian action will not take place.


3) add properties to just set or translate one component of eye at a time.
For example
void eyeY(float new_y) { _eye.y = new_y; //do something more }
Then instead of cam.eye.y = 5 you have cam.eyeY = 5.


count of such separate methods will became innumerable at some moment


4) don't do anything and just leave the eye setter as the only way to change
_eye. I don't think users will be confused by the behavior of cam.eye.y = 5


I think expression cam.eye.y = 5 is very natural and so such constructions,
writen because of blunder, can lead to hiden bugs hard to find.
Dec 20 2004
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
[snip]


4) don't do anything and just leave the eye setter as the only way to




change

_eye. I don't think users will be confused by the behavior of cam.eye.y =




5

 I think expression cam.eye.y = 5 is very natural and so such


constructions,

 writen because of blunder, can lead to hiden bugs hard to find.


So what about code like
 void foo(Vector3 w){w.y = 5;}
 ...
 foo(cam.eye)
Does it modify the original values in cam? I would be surprised if it did -
but then I'm not at all surprised that cam.eye.y changes a copy. Or if you
really want to you can try something like

struct EyeRef {
  Vector3* eye;
  Camera cam;
  ...
  void y(float new_y) {
    eye.y = new_y;
    cam.doSomething();
  }
  Vector3 toValue(){ return *eye; }
}
class Camera {
  ...
  EyeRef eye() {
    EyeRef e;
    e.cam = this;
    e.eye = &_eye;
    return e;
  }
}

That way cam.eye.y = 5 will set the _eye.y value in cam and call doSomething
in cam afterwards - which I think is what you want to have happen. Writing
cam.eye.toValue will return a copy of the Vector3. Making the language more
complex should be a last resort.
Dec 20 2004
prev sibling parent reply pragma <pragma_member pathlink.com> writes:
Nail, try changing your example to use the following:


public Vector3* eye()
{
    return &_eye;
}


Pointers aren't preferred in D (they're ugly), but they do exist for reasons
aside from legacy compatibility.  In this case, simply return a pointer to the
struct you wish to access and all will be well.  You won't have to change
anything else, so don't worry about your code bloating up too badly.

Also, if you're exposing a member in this fashion (exposing the whole struct),
you might want to do away with an accessor completely.  If there are no in/out
clauses in your accessors, you're not gaining anything by that extra function
call.  :)

I, like yourself, first expected structs to be pass-by-reference much like
classes are; obviously, they are pass-by-value.  The more D code I wrote, the
more I became to realize that structs are more like heavyweight scalars than
lightweight classes.  They still have to obey the copy-on-write rule as other
scalars do.

I think this isn't a flaw in D's design, but rather a deliberate move on
Walter's part to provide compatibility with C.  To that end, it lets you do *at
least* as much as C/C++, and then some.

- Pragma at yahoo
Dec 20 2004
parent nail <nail_member pathlink.com> writes:
I, like yourself, first expected structs to be pass-by-reference much like
classes are; obviously, they are pass-by-value.  The more D code I wrote, the
more I became to realize that structs are more like heavyweight scalars than
lightweight classes.  They still have to obey the copy-on-write rule as other
scalars do.

I think this isn't a flaw in D's design, but rather a deliberate move on
Walter's part to provide compatibility with C.  To that end, it lets you do *at
least* as much as C/C++, and then some.


Maybe yo're right. The time will show.
Dec 20 2004