From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-04-23 13:16:57
>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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk