On Thursday, 14 February 2013 at 19:31:36 UTC, Steven
Schveighoffer wrote:
If it was pass by ref, then rbt.insert(5) would not work. And
in fact, I wouldn't want things passed by ref if the element is
int.
What is the reason for the second objection - is just performance?
Is performance really an issue?
From this thread it looks like fundamental types by ref or value
is not really a big deal in terms of performance. OTOH - as size
and/or postblit execution gets expensive the cost *is*
significant.
---------------------------
4 bytes: using cref_(int size) took 29[ms]
4 bytes: using inref(int size) took 29[ms]
4 bytes: using in___(int size) took 30[ms]
8 bytes: using cref_(int size) took 29[ms]
8 bytes: using inref(int size) took 28[ms]
8 bytes: using in___(int size) took 31[ms]
...
128 bytes: using cref_(int size) took 29[ms]
128 bytes: using inref(int size) took 29[ms]
128 bytes: using in___(int size) took 290[ms]
---------------------------
I have to admit, I did not consider expensive postblits when I
designed it. Almost all my testing is with integer types.
For performance, it seems by ref should always be preferred in
generic code because you can not know the cost of postblit - or
copy construction if that were a future solution for structs.
Granted the no rvalue passing is a pain - but is it a big deal in
library/generic code?
Thanks,
Dan
