Re: [boost] Re: class proposal

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

"Justin M. Lewis" wrote:
> 
> in/out seems to be used fairly commonly in COM.  I'm not sure I have any
> great examples off the top of my head, but I know they're commonly used.

I'm not a COM person, but I believe it's written in C.  If so, then you
are correct that in/out parameters are more needed since noone would
want to create a struct for each multiple return type.

OTOH, C++ has templates to deal with this situation (ie boost::tuple<>)
so, qualifying my previous statement, in C++ I still see no need for
in/out parameters.

> And using pointers is part of what we're trying to avoid here.  Like I said,
> I avoid using pointers whenever possible at this point.

I'm a little confused.  Either you pass in the entire object or you pass
in a pointer (even if it's wrapped in another class).  How is this new
class supposed to be implemented?

> And, again, the real intent here is to insure clarity at the point of
> invocation.  In my case I'm looking at 100's of thousands of lines of code,
> written over the past 8 years.  It's tiresome trying to chase down where
> values COULD have changed.  In this setup you KNOW exactly what calls are
> changing parameter values, and it's enforced.  As long as the library calls
> use the c_out and c_in_out classes people using the library are forced to
> conform to the format.  So, 8 years, and a few million lines of code later,
> no one will wonder what might cause a variable they're tracking to change
> values.

I think if parameters are used for in parameters only and return values
are used for out parameters only, the same thing is achieved.  For
example,

  inOutValue = square( inOutValue );

vs (using an extension for generality):

  square( c_in_out< typeof( inOutValue ) >( inOutValue ) );

Noel