Re: [boost] in/out parameters, coding styles and maintenance [was: class proposal]

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-04-24 16:51:20

Sorry, I haven't posted the actual code yet.  I'll look into doing that
after I get home from work.  I'm sort of new to this whole mailing list, I
wasn't really sure of the whole procedure.

Justin

----- Original Message -----
From: "Augustus Saunders" <infinite_8_monkey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, April 24, 2003 2:42 PM
Subject: [boost] in/out parameters, coding styles and maintenance [was:
class proposal]

> It seems we've stirred up a little discussion here under the
> inauspicious subject of class proposal, and I wanted to add my 2
> cents.  In summary, the original poster was frustrated by the
> anonymity of passing parameters as non-const references.  He then
> proposed a wrapper class that a library writer could use instead of
> pass-by-reference which would make code calling the library very
> clear as to which paramters were in parameters and which were out
> parameters.  From there, we were diverted off into discussions on the
> use of const, clarifying what Justin was going after, talk about
> using tuples for return values, and talk about potentially inept
> coworkers.  I would like to bring the discussion back to a couple of
> points I find more relevant to boost (interesting discussion though
> it may be):
>
> 1) We normally pay a lot of attention to safety of usage, clarity of
> intent, confusion from subtle semantics etc in our discussions.
> Sometimes we might even belabour the point (though I think it's
> healthy).  This question goes to the library writers here.  Would you
> replace:
>
> int foo(int &param);
>
> with
>
> int foo(in_out_param<int> param);
>
> provided that the in_out_param had no space/time overhead.  Actually,
> the only proposed benefit is to force the usage of foo from
>
> void MyFunc(int height)
> {
>     cout << height << endl;
>     foo(height);
>     cout << height << endl;  // Hey!? What happened?
> }
>
> to
>
> void MyFunc(int height)
> {
>     cout << height << endl;
>     foo(in_out_param(height));
>     cout << height << endl;  // Ok, height changed as expected.
> }
>
> Of course, some library users will find the requirement to wrap up
> their parameters irritating.  Additionally, if it's not a widespread
> idiom, it could be confusing to people unfamiliar with it.
>
> 2) Is this usage going to be so idiomatic that it should be left up
> individuals to decide what they want to do with it?  Is it along the
> lines coding guidelines that some companies have?  Some places I have
> worked, we had exotic iterator adapters and other utility classes.
> Would this just be like that?  Unless I'm missing something, it
> shouldn't be too hard to implement.
>
> 3) On the other hand, since a major goal of such a utility is to be
> ubiquitous and unobtrusive, is it something that we should hash out
> "good" syntax for and shine a light on all the quirky corner cases?
>
> On the surface, the idea does not seem unreasonable to me.  But the
> proposed usage syntax for library user feels a little heavy handed.
> Lastly, if the proposed implementation has been posted, I missed it,
> so can somebody post it or a link again?  Thanks-
>
> Augustus
>
> __________________________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo
> http://search.yahoo.com
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>