Regan Heath regan at netwin.co.nz
Sat Mar 18 02:37:00 PST 2006


On Sat, 18 Mar 2006 23:14:46 +1300, Regan Heath <regan at netwin.co.nz> wrote:
>> 3. you cannot call operators from pointers, without adding in *  
>> everywhere.

I should mention that some operators, i.e. += don't work so well either.

So, yeah, there are some problems with the pointer syntax. I think if  
you're running into these sorts of things you should consider using a  
class instead of a struct.

Regan

> Partially true, i.e. when you're trying to add two Foo* together,  
> however you can add the following to the Foo struct to add a Foo* to a  
> Foo:
>
> 	Foo opAdd(Foo rhs)
> 	{
> 		Foo n;
> 		
> 		n.x = x+rhs.x;
> 		n.y = y+rhs.y;
> 		n.z = z+rhs.z;
> 	}
> 	
> 	Foo opAdd(Foo* rhs)
> 	{
> 		return opAdd(*rhs);
> 	}	
>
> Regan
>
>
>> In article <ops6i24bii23k2f5 at nrage.netwin.co.nz>, Regan Heath says...
>>>
>>> On Thu, 16 Mar 2006 06:34:34 +0000 (UTC), Hong Wing
>>> <Hong_member at pathlink.com> wrote:
>>>> Thanks everyone here for your great work in D, especially Walter who
>>>> makes it
>>>> all happen.
>>>> Here I am requesting a feature, which is "inout variable" and "inout
>>>> return
>>>> type"
>>>> Rationale, for the example below,
>>>>
>>>> struct Foo
>>>> {
>>>> int x, int y, int z;
>>>> }
>>>>
>>>> class Bar
>>>> {
>>>> private:
>>>> Foo m_foo;
>>>> public:
>>>> Foo foo() { return m_foo; }
>>>> Foo foo(Foo value) { return m_foo = value; }
>>>> }
>>>>
>>>> now if i want to change the value of m_foo.x to 5, i have to do
>>>>
>>>> Foo foo = bar.foo;
>>>> foo.x   = 5;
>>>> bar.foo = foo;
>>>>
>>>> it would be nice if I can define a return type as "inout Foo"
>>>> inout Foo foo() { return m_foo;}
>>>>
>>>> To extend it further, one might want to define inout variables as
>>>> inout Foo foo = bar.foo;
>>>>
>>>> Advantages:
>>>>
>>>> 1. efficiency, one can directly change the states of the struct  
>>>> instead
>>>> of
>>>> making a copy first, change the copy, and put the result back to the
>>>> struct
>>>>
>>>> 2. less buggy, having to type 3 lines always increases chance of bugs,
>>>> also,
>>>> someone might inadvertantly do bar.foo.x = 5 and forgot that he is
>>>> working on a
>>>> copy
>>>>
>>>> 3. reduce the use of pointers, the above can be achieved using  
>>>> pointers,
>>>> but it
>>>> means defining two versions of the same method every time a struct
>>>> property is
>>>> written.
>>>
>>> You're essentially asking for the ability to have variables which are
>>> references to structs (at least during assignment) and to return
>>> references to structs, all without using the pointer syntax. I think  
>>> these
>>> things are un-necessary, and I think what you want can be achieved with
>>> pointers, without the penalty you mention in #3 above, see:
>>>
>>> import std.string;
>>> import std.stdio;
>>>
>>> struct Foo
>>> {
>>> 	int x;
>>> 	int y;
>>> 	int z;
>>> 	char[] toString() { return
>>> "("~std.string.toString(x)~","~std.string.toString(y)~","~std.string.toString(z)~")";
>>> }
>>> }
>>>
>>> class Bar
>>> {
>>> private:
>>> 	Foo m_foo;
>>> public:
>>> 	Foo* foo() { return &m_foo; }
>>> 	Foo* foo(Foo* value) { m_foo = *value; return foo(); }	
>>> 	Foo* foo(Foo value)  { m_foo = value;  return foo(); }
>>> }
>>>
>>> void main()
>>> {
>>> 	Bar b = new Bar();
>>> 	Bar c = new Bar();
>>> 	Foo t;
>>> 	
>>> 	b.foo.x = 1;
>>> 	b.foo.y = 2;
>>> 	b.foo.z = 3;	
>>> 	writefln(b.foo.toString());
>>> 	
>>> 	c.foo = b.foo;
>>> 	writefln(c.foo.toString());
>>> 	
>>> 	t.x = 4;
>>> 	t.y = 5;
>>> 	t.z = 6;
>>> 	writefln(t.toString());
>>> 	
>>> 	b.foo = t;
>>> 	writefln(b.foo.toString());
>>> }
>>>
>>> Note: The explicit "toString" calls are required because otherwise it
>>> prints the pointer address.
>>>
>>> Regan
>>
>>
>




More information about the Digitalmars-d mailing list