>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
