Boost logo

Boost :

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.


----- 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
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at