Re: A Brief Introduction to Rvalue References
Posted: Mar 21, 2008 9:24 AM
> > C++ is fast enough as it is.
> Many people disagree. In particular, if you want to write
> simple programs using value semantics, the cost of copying
> can become a problem.
If your program is so simple that it can only have value semantics, then it can be written in such a way that no copying is required. Copying is costly mainly when allocations are involved. If allocations are involved, then you don't have only value semantics, you also have reference semantics, albeit hidden.
On the other hand, if your program is so sensitive in performance that it needs that extra ounce of efficiency gained by rvalues, then it's not that simple, is it? in that case, you will have already coded your algorithms in such a way that redundant copying would not exist.
Rvalue references - which after all
> is the source of this particular debate - were introduced
> to transparently eliminate redundant copies. When used
> right (meaning under the covers of a class needing value
> semantics) they simply eliminate waste - they are an
> optimization mechanism. The problem they address is beyond
> the scope of current and likely near-future optimizers.
But redundant copies exist because objects are allocated in scoped memory (i.e. the stack). Instead of fixing the source of the problem, you provided a patch, whereas fixing the problem will have solved a much greater spectrum of problems without introducing new ones.
> > Due to lack of garbage collection, C++ is not used
> > ...
> C++ will get GC. GC is not a panacea, though, and about as
> many complain about the possibility of the ("useless,
> complex, and redundant") GC as do complain about its
> current absence.
> I would have liked to see (programmer controlled) GC in
> C++0x, but I'll have to wait for a TR. IMO *many* will
> benefit from GC and *many* will live happily without using
> it even after it becomes standard.
Why should they complain if it is optional? I do not claim that all C++ objects must be allocated on the heap. Stack allocation has important efficiency benefits, as well as RAII (very useful).
> > Methinks the new move semantics in C++ are there just
> > because you could do it, and for no other reason.
> You happen to be wrong about that. Rvalue references (move
> semantics) addresses a well known and significant problem
> with one of the most popular programming styles.
RValue references addresses a well known and significant problem which would not have existed if other solutions were preferred in the first place. By insisting on manual memory management, the need to avoid copying arises, which in turn makes rvalues seem a good solution.
Let me put it in this way: what needs to be moved with move semantics can be allocated on the heap using garbage collection and therefore all issues of language complexity and run-time efficiency, etc could be avoided.
The inclusion of smart pointers in the standard library points to the need of automating the task of memory management.