RE: [boost] Re: class proposal

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-04-23 17:07:16

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: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] 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ø" <tslettebo_at_[hidden]>

> >From: "Justin M. Lewis" <boost_at_[hidden]>
>
> > 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