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

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-02 03:42:24

----- Original Message ----- 
From: "Joel de Guzman" <djowel_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Thursday, May 01, 2003 5:44 PM
Subject: Re: [boost] in/out parameters,
codingstylesandmaintenance[was:classproposal]

> 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:

You're right, I can't claim that this will be used in all code, in all
projects, throughout the universe.  I don't think I've ever made that claim,
like anything else, it's up to the people writing the code to adhere to
coding guidelines.  The POINT here is, you CAN use this library in a project
to make your intent clear at the point a function is called.  And, this
whole point of retrofitting, am I the only person planning on writing new
code ever?  You don't need to retrofit EVERYTHING to put a new idea to use.
You can choose to just start using it going forward, or pick it up at the
beginning of the next project.  And, while YOU may personally never use it,
that doesn't mean no one will.

>
>     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.
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>