RE: [boost] in/out parameters, codingstylesandmaintenance

From: Glen Knowles (gknowles_at_[hidden])
Date: 2003-05-02 01:37:54

From: Joel de Guzman
>> It doesn't need to be used everywhere in every project.  The point
>> is, if you're starting something new, and you can be fairly sure that
>> it's going to be used for years to come, you can start a project with
>> it.  I'm not suggesting that you use it IN the boost libraries even. 
>> I just see it as a useful utility for anyone who would like to use it
>> to keep their own code clear.

>I'll repeat myself: It won't have teeth if it's not enforced. The
>problem is that you can't enforce it. You keep on saying that the goal 
>is so that the coder would be saved "the trouble of having to hunt down 
>all kinds of functions to find out if and when you can expect your 
>variables to change". If it's not applied globally, then the coder will 
>be as confused as before. She'll still have to hunt down all function 
>calls to find out if and when her variable will be changed or not. The 
>case-by-case nature of your solution will cause more confusion, AFAICT. 
>When you see:
>
>    foo(a, b, c)
>
>Are you 100% sure, without looking at the docs or the API, that
>a, b or c is not modified? The only plausible answer is: that depends,
>if foo is retrofitted or not. *** That's the problem ***.  Anything less
>than 100% guarantee is false security.

There is merit in what you say, that if you're going to do this the best way
to do it is in the language, and I think that's the only thing that would
get me to use it. OTOH, you're definitely seeing the glass as half empty.
Its true that you can't always know for sure, but there is _some_ value in
the fact that if you see:

foo(out(a), b, c)

you _know_ that a is going to be changed.

Glen