On Saturday, 2 March 2013 at 08:29:25 UTC, Namespace wrote:
Era Scarecrow:
Did I understand right that your answer is 'No, we don't need
something like const&'?
const& is ugly and suggests it is using a pointer which we don't
want to use except in low level stuff. const& doesn't make sense,
but 'auto ref' does, and I think it could be quite useful.
On Saturday, 2 March 2013 at 09:38:17 UTC, deadalnix wrote:
On Saturday, 2 March 2013 at 09:31:56 UTC, Namespace wrote:
On Saturday, 2 March 2013 at 09:38:17 UTC, deadalnix wrote:
1/ Generic code. You may not know that the data are big after
starting conglomerating more and more stuff.
auto ref for templates still exists and won't get away.
Passing by ref small struct for nothing is also a performance
concern. You'll access them via dereference when you could have
them directly in registers, and reduce the compiler capability
of doing optimization based on aliasing.
Auto ref is convenient, but look more like an ugly patch than a
real solution.
And if it's not implemented I'll be doomed making the same
forwarding functions due to ref & const preference rules. I can
live with it but I don't want to. I'm not saying I'll use auto
ref for everything, only when it makes sense to.
2/ Data may be small, but with an expensive copy mechanism.
Example?
struct ValueArray(T) {
T[] data;
alias this = data; // Damned, it is broken on 2.062
this(this) {
data = data.dup;
}
}
Perhaps enlarge the example just a touch...
alias ValueArray!ubyte BigUbArray;
BigUbArray array = new ubyte[1<<20]; //1 meg
static assert(BigUbArray.sizeof <= 16);
//gee 'BigUbArray' is only 8-16 bytes!!! postblit!
void func(BigUbArray s);
If it's POD however then it shouldn't have any
modifications/postblit or anything special to worry about.
