On Wednesday, 19 October 2016 at 15:18:36 UTC, Atila Neves wrote:
[...]
On the one hand some people want rvalues to bind to const ref.
I can only assume that they want this because they want to pass
rvalues to a function efficiently
[...]
struct Vector { float x, y, z; }
In games/real-time simulations, we have to deal with 4x4
float/double matrices. They're not big enough to warrant a heap
alloc(like opencv's cv::Mat) but not small enough that you want
to arbitrarily copy them around either. When you have a scene
with thousands of nodes, all the extra copying will be a huge
waste.
I cringe every time I see someone getting all religious about
profilers. There isn't always one big thing that's responsible
for your slowdown.
The situation is this: if one wants move semantics, one must
know when one can move. Because rvalues bind to const& in C++,
you never know whether the const& is an lvalue or rvalue. The
solution to this was rvalue references, which are refs that can
_only_ bind to rvalues. That way you know that the origin was
an rvalue an wahey, move semantics. They complicated the
language significantly. Did you know there's more than one kind
of rvalue in C++? Oh yes:
I don't understand the situation completely here.
void foo(ref Bar bar){}
void foo(Bar bar){}
Why do these have to be ambiguous? Can't the compiler just prefer
the second overload for rvalues?
In C++, you _must_ differentiate between move constructors and
by-value constructors because of the eager copying that happens
when you pass things like std::vector by value. I suggested a
similar convention for D containers though, and Andrei was
strongly opposed to the idea of eager-copying value-type
containers. If things go this way, then aren't the above two
overloads enough?
Bit
