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 v3); 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. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Terje Slettebų Sent: Wednesday, April 23, 2003 11:17 AM To: Boost mailing list Subject: Re: [boost] Re: class proposal >From: "Terje Slettebų" <[EMAIL PROTECTED]> > >From: "Justin M. Lewis" <[EMAIL PROTECTED]> > > > Well, I guess, based on all the code I've been reading at work it didn't > > seem so small, chasing down all kinds of functions across 100's of files > > to see why exactly values are changing mid function I'm looking at > > without warning. > > > > Anyway, this would allow for stronger enforcement of the rule that > > changing params should be marked somehow. As the programmer of a > > library people are using, I can force them to mark the params they're > > passing as out or in_out, so in 5 years when someone else comes along > > and has to debug it, it's all clear what's happening. > > Why not use T & if the function may change it, and const T & if it won't? After I sent it, I realised that the issue was marking it at the _caller's_ side, so then this doesn't apply. It was a little difficult to understand the proposal, as it mentioned c_in_out and c_out, while the code example uses CRetVal and the retval function. Regards, Terje _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost