Multiple return values...

[Manu]

On 8 March 2012 22:13, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:

> On Thu, Mar 08, 2012 at 10:08:41PM +0200, Manu wrote:
> > I find myself really wishing for proper multiple return values almost
> every
> > day, particularly when I work with maths heavy code, and especially for
> > efficiently returning error codes in functions I'd rather not throw from.
> > Many maths-y functions return some sort of pair; intersections return
> (ray,
> > t) or something of that type.
> > I'm finding HEAPS of SIMD functions want to return pairs (unpacks in
> > particular): int4 (low, hight) = unpack(someShort8);
> > Currently I have to duplicate everyting: int4 low =
> > unpackLow(someShort8); int4 high = unpackHigh(someShort8);
> > I'm getting really sick of that, it feels so... last millennium.
> >
> > The point of 'proper' multiple return values is to return each value in
> > registers, in its own register type, using exactly the same register
> > assignment pattern as when passing args TO functions.
> > I don't think this causes any side effects to the ABI, since the arg
> > registers are already volatile across function calls in the first place.
> > It just means that the returned-to function can find its return
> > values already conveniently in an appropriate register, avoiding memory
> > access.
> >
> > People argue I should return a tuple, but this isn't really the same, it
> > has hidden implications that complicate the optimisation potential. For
> > instance, tuples have an implicit structure/memory layout which can't be
> > ignored, whereas return values don't have memory allocated, ie, you can't
> > take the address of a return value without first assigning it to some
> local
> > syntactically.
> [...]
>
> Couldn't you just use ref parameters? Or does the compiler turn them
> into pointers?
>

ref parameters are pointers by definition. That's not what I'm talking
about.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120308/6c3e4d8d/attachment.html>