D dropped in favour of C# for PSP emulator

[Manu]

On 12 May 2012 13:13, Jonathan M Davis <jmdavisProg at gmx.com> wrote:

> So, basically it's just the issue with neither ref nor const ref taking
> lvalues.


And the local references, and the bug.

If you duplicate the functions (or use auto ref if they're templated
> functions), then it's not an issue.


Yes it is. Passing by value is NOT passing by reference, it's a totally
different operation. And what about non-const ref?
'in ref' would be very nice if it worked. It would basically replace 'const
ref'.

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.


Well there's the bugs we've seen in optimised codegen.
Duplicating with non-ref is not a solution. It's not even a workaround. The
only workaround is to receive a pointer, which ruins all those cases in
terms of syntax anyway.

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).
>

Well I think it's safe to say most people pass data structs by reference.
If I saw someone pass a struct by val, I'd consider it a bug/typo and fix
it.
You might say to use a class in D, but classes aren't a pure data structure
like they are in C; I see them as being for fundamentally different
purposes, and I wouldn't use a class to express a struct.
Classes also ruin strict data layout and alignment of members. I don't
think that's a valid workaround either, it's effectively abusing the very
_concept_ of classes in D.

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.


Awesome, although it doesn't end there. Local references are also very
important.

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.
>

What are these issues I keep hearing about? I'm not aware of any
fundamental problem with ref in C++...
Can you show an example of the problem the design is trying to avoid?

> That's not a solution, it's not even a work around, it's a totally
> > different operation. I may not want to, or can't, pass my data by value.
>
> Whether passing by value makes sense depends on the struct. If it has lots
> of
> members, then no, passing by value doesn't work very well (though still
> not as
> badly as C++98 thanks to the fact that D can move structs far more often
> due
> to its different copy semantics). But almost all of the structs that I deal
> with only have a handful of member variables at most, so the cost of
> passing
> by value isn't high. In most cases, if I have a lot, I probably wanted a
> reference type anyway, in which case, I'm almost certainly going to use a
> class.
>

Well, in my line of work, if the cost of passing by value is greater than
the cost of passing by reference, then the correct thing to do is to pass
by reference. There is zero tolerance for wasting memory accesses on such a
trivial operation.
The only case where the cost of passing by value is ever less than by
reference is if the struct contains a single primitive value for which the
CPU has a dedicated register type. This is the only time we would ever
tolerate passing by value.

But there's no question that the situation with const ref needs to be
> improved
> (it was discussed quite a bit on the beta list during the last beta).
> Fortunately, that's likely to happen sometime soon.


That's a shame, it's been coming up every day for me the last couple of
weeks. I have workarounds in almost every source file, and some cases where
a workaround is impossible, which pollutes the code at the point of use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120512/168e29f8/attachment.html>