D dropped in favour of C# for PSP emulator

Timon Gehr timon.gehr at gmx.ch
Sat May 12 03:22:40 PDT 2012


On 05/12/2012 12:13 PM, Jonathan M Davis wrote:
> On Saturday, May 12, 2012 13:03:26 Manu wrote:
>> On 12 May 2012 12:37, Jonathan M Davis<jmdavisProg at gmx.com>  wrote:
>>> On Saturday, May 12, 2012 11:26:37 Timon Gehr wrote:
>>>> On 05/12/2012 10:13 AM, Manu wrote:
>>>>> On 11 May 2012 21:28, Mehrdad<wfunction at hotmail.com
>>>>>
>>>>> <mailto:wfunction at hotmail.com>>  wrote:
>>>>>      Yes, I agree, but consider that D users should NOT have to work
>>>
>>> with
>>>
>>>>>      pointers to do something so basic
>>>>>
>>>>> I'd like to think this were true, but the fact that 'ref' barely works
>>>>> makes this almost immediately false when trying to write any
>>>
>>> non-trivial
>>>
>>>>> program.
>>>>
>>>> It depends on the coding style.
>>>
>>> I rarely end up passing by either ref or pointer, and the only issues that
>>> I've ever had with ref relate to the fact that you can't pass it rvalues.
>>> Obviously both pointers and ref have their uses, but I'd definitely have
>>> to
>>> concur that it depends on your coding style and what you're doing. Also, I
>>> really don't know what's wrong with ref such that anyone could say that it
>>> "barely works" other than the issues with rvalues and functions which take
>>> ref
>>> or const ref.
>>
>> struct X
>> {
>> int i;
>>
>> X opBinary(string op)(const ref X b) if(op == "+") { return X(i + b.i); }
>> ref X opOpAssign(string op)(const ref X b) if(op == "+") { i += b.i; return
>> this; }
>> ...etc
>> }
>>
>> ref X func(ref X x)
>> {
>> return x;
>> }
>>
>> bool maybe()
>> {
>> return (time()&  1) != 0;
>> }
>>
>> void test()
>> {
>> X a,b,c;
>> X v[];
>>
>> func(a); // this is basically the only expression that works
>> X t = a + (b + c); // fail
>> a += b + c; // fail
>> ref X t = func(a); // fail
>> func(a + b); // fail
>> func(maybe() ? a : b); // this generates bad code:
>> http://forum.dlang.org/thread/cnwpmhihmckpjhlaszzy@forum.dlang.org
>> ref X t = v[some + complex * (expression + that_i_dont_want_to_repeat())];
>> // fail
>>
>> foreach(i; 0..10)
>> {
>> ref X t = v[some + expression * involving - i]; // fail
>> }
>> }
>>
>> Just a couple of extremely common usage patterns that come to mind. I'm
>> sure there are many more...
>
> So, basically it's just the issue with neither ref nor const ref taking
> lvalues. If you duplicate the functions (or use auto ref if they're templated
> functions), then it's not an issue. It sucks to have to duplicate stuff, but
> ref works just fine as long as you don't assume that it's going to allow you to
> pass rvalues to it. Personally, I almost always just have functions take
> structs by value, so it's a non-issue except for stuff like opEquals, which
> requires const ref (for at least one overload anyway).
>
> However, given the ridiculousness of having to duplicate functions to make ref
> usuable for any case where you're specifically trying to avoid a copy rather
> than use it to pass a value out, Andrei and Walter are looking at making ref
> work with rvalues. They just have to sort out how to avoid the issues that C++
> has due to allow const&  to take rvalues (which is why const ref in D doesn't
> currently take rvalues). So, there's a good chance that the situation will
> improve considerably sometime soon.
>
> - Jonathan M Davis

I don't see why 'const' should make a difference there anyway. It is 
completely orthogonal. It could be argued that the callee might assume 
that his changes will be visible for the caller, but if the point of 
passing an rvalue by reference is to gain performance, forbidding the 
callee to use it as scratch space is just ridiculous.


More information about the Digitalmars-d mailing list