Re: [boost] in/out parameters, coding stylesandmaintenance[was:classproposal]

From: Joel de Guzman (djowel_at_[hidden])
Date: 2003-05-01 19:44:53

Justin M. Lewis wrote:

> I'm not sure I follow the comments below, except ultimately that you
> don't like the idea.

Wierd. I thought the opposite. I too have always liked the idea
of clear in out parameters. However, just like Paul, bluntly speaking, 
I am convinced that your implementation of the idea is of little value 
in C++.

> As I see it, these in/out and out params come at no runtime cost. 
> And they help make clear otherwise potentially confusing function
> calls.  They would save you the trouble of having to hunt down all
> kinds of functions to find out if and when you can expect your
> variables to change. 

Your intent is good. However, you cannot claim that we'll all be 
saved from the "trouble of having to hunt down all kinds of functions",
unless, and that's a big unless... *ALL* functions and function calls are 
retrofitted with your inout solution. If this is not done wholesale,
the programmer will still be uncertain as to which functions will modify
his argument. I imagine him faced with a function call:

    foo(a, b, c, d)

In his mind: "Is this a no-side-effect call? No assurance. I'm not sure
if it's retrofitted by the cool io-param feature". Worse, he'll see:

    bar(in_out(a), b, c, d)

Is this an assurance that only 'a' can potentially be modified? Yes?
Really? What's to stop a crazy programmer from using in_out for
'a' and a reference for 'b' or 'c', or 'd'?

The biggest problem is that *it is not enforced by the language*.

> I really can't see any reason to NOT use a technique like this.  I
> mean, it ultimately helps make clear things that otherwise are not,
> at the cost of typing a few more characters in the few instances
> where functions take 
> in/out and out params.

IMHO, your intent is good but any solution won't deliver its
promise unless it is enforced wholesale. This can only be done
by changing the language.

-- 
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net
> ----- Original Message -----
> From: "Paul A. Bristow" <boost_at_[hidden]>
>> I've followed this long discussion, but I am left feeling like the
> Irishman
>> replying to a request for directions "Well, I wouldn't start from
>> here!". 
>> 
>> Languages designed using rational thought from good basic premises,
>> like Ada, have explicit in, out and inout parameters. Sadly C++ has
>> growed like 
> Topsy from
>> some dodgy articles of faith.
>> 
>> C++ only has confusing consts, but conventionally we don't even
>> apply it 
> to
>> procedure parameters (double log(const double); is clear but causes
> trouble and
>> sometimes appears to impede optimisation).
>> 
>> So I too am unconvinced that the sticking plaster proposed is useful
>> even 
> as
>> first aid.