On Wednesday, 7 November 2012 at 04:36:59 UTC, Era Scarecrow
wrote:
Maybe... But when working with non built-in types can you
guarantee that behavior?
Sure, try it out.
What you are referring to here has nothing to do with rvalues. It
is about side results which are only sometimes needed. It is
clear that you have to use lvalue arguments for those in order to
access them after the function call. Using bogus rvalue arguments
in case you're not interested in them wouldn't really help -
you'd save the variable declaration, but the function signature
would still be ugly, and you can't always provide hypothetical
default values to hide them (depending on parameter order). In my
experience, these cases are very rare anyway (unless dealing with
porting old C-style code which you seem to be doing) and function
overloading is the most elegant way to handle it - take a look at
the large number of overloads in modern language libraries such
as .NET.
This is how I would implement it:
// magical, super-fast function ;)
int divide(in int number, in int divisor, int* remainder = null);
auto bla = divide(13, 4); // => 3
// remainder needed as well, hiding the pointer as reference:
int divide(in int number, in int divisor, out int remainder)
{
return divide(number, divisor, &remainder);
}
int remainder;
auto bla = divide(13, 4, remainder); // => 3, remainder = 1
// only remainder needed:
int modulus(in int number, in int divisor)
{
int tmp;
divide(number, divisor, tmp);
return tmp;
}
auto bla = modulus(13, 4); // => 1
But this is all really off-topic here, let's stop spamming this
thread.
