Re: [boost] Re: class proposal

From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-04-24 06:18:09

"Justin M. Lewis" wrote:
> 
> I agree.  I probably wouldn't have cared for this myself, had I never seen
> the code I'm working on now.  I mean, normally I work pretty independently.
> But, now I'm stuck with the job of maintaining code that's been around
> forever, has been ported several times to a couple different projects.  In
> places you can see how the code evolved over time.  But, the point is, it's
> becoming a mess.  And, we're at a point where we're almost starting
> everything again, but this time from scratch.  Knowing that the code will
> probably live for years, and be ported several times, and be maintained by
> many different people over its life, it seems best to me to start a project
> like that off with clarity being the #1 priority.  And, at least in my
> experience, people seem to think that functions that pass by reference
> changing the values of params is a problem, it's hard to track.  But, most
> C++ people I know prefer to avoid pointer use.  So, that really only leaves
> the one option that makes the intent explicit and clear, every time.
> 
> So, I really can't give a long term analysis of how well this method works,
> if it becomes a hassle to maintain it, or not.  But, as it is, it seems more
> clear to me than anything else.  At the cost of 3 or 6 letters at the
> invocation point, you can make the operation of the function clear.
> 
> func(out(x));
> 
> It seems pretty simple and straight forward to me.

I believe all that will be accomplished is that these objects will
become ubiquitous in the system just as references are.  For example,
code like the following will start to pop up:

  void f( in_out< int > is_not_changed_ )
  {
    // use is_not_changed_, but don't change it
  }

IMHO, why not just state from the start to ban in/out parameters?  In
its place, use parameters for "in" and return for "out".  An in/out can
done via a smart pointer.

Noel