On 12 May 2012 13:13, Jonathan M Davis
<jmdavisProg@gmx.com> wrote:
So, basically it's just the issue with neither ref nor const ref taking
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.