Andrei Alexandrescu:
> I just don't want inefficiencies; returning e.g. a large struct will
> still involve some memcpying even if costly resources are not duplicated.
If a larger and more complex API can be tolerated, then you can add a method to
remove the last/first item without returning it (so the pop methods return it).
To append items you can use tilte-equal operator, and to prepend you may use
the ".prepend(...)" method.
Another silly possibility is, inside the pop methods, identify in some way the
code that returns the value, and don't compile it. So the compiler is able to
almost automatically create two return-overloaded functions, one that returns
and one that doesn't return. To do this the programmer may add some tag, or the
compiler may do it automatically, removing the "return" from a second version
of the function, and then removing dead code that created the data that is
given by the return.
>Making one private or undefined would prevent statically that people call
>functions and ignore error codes.<
I think this is an important enough thing; GCC too thinks it's important
because it allows this function attribute:
warn_unused_result
The warn_unused_result attribute causes a warning to be emitted if a caller
of the function with this attribute does not use its return value. This is
useful for functions where not checking the result is either a security problem
or always a bug, such as realloc.
int fn () __attribute__ ((warn_unused_result));
int foo ()
{
if (fn () < 0) return -1;
fn ();
return 0;
}
results in warning on line 5
Bye,
bearophile
