From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-04-23 19:34:32
On Wednesday, Apr 23, 2003, at 16:07 America/Denver, Justin M. Lewis
> Sorry if the explanation is a bit confusing. The whole idea here is to
> make it explicit at the function invocation that a parameter being
> passed will be used to return a value.
> A good example of where this would be useful is with a function call
> that takes some params, and returns several different things in
> different params, and still has an explicit return for an error code.
> At the invocation point it would be impossible to tell what's going on.
> int chk;
> chk = GetSomething(p1, p2, p3, p4, p5);
> where the actual declaration of GetSomething is like
> int GetSomething(int &ret1, int &ret2, int v1, int v2, int v3);
> It's impossible to tell at the invocation which params are returning,
> and which are being used to calculate the return. At the invocation it
> looks like chk might be what you're trying to get.
> With classes like I'm suggesting it would be obvious, the declaration
> would be:
> int GetSomething(c_out<int> ret1, c_out<int> &ret2, int v1, int v2, int
> And at the invocation now, it has to be explicit that those first 2
> params are out params.
> chk = GetSomething(out(p1), out(p2), p3, p4, p5);
> It REQUIRES you to use the out helper function at the invocation, so
> anyone reading the code later can see, without checking the
> implementation of GetSomething, that those 2 params are being set, and
> the last ones are not.
Is this really that much better than
chk = GetSomething(&p1, &p2, p3, p4, p5);
GotSomething ret = GetSomething(p3,p4,p5);
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk