Re: [boost] Re: class proposal

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-04-24 10:12:43

Everyone is ignoring the possibility of objects that can't be copied in
this, too.  Some objects intentionally hide their operator =, making
returning it from a function impossible.

And, I think a lot of people are missing a big part of the point here.  You
can enforce the use of making it explicit at the point of invocation that
the param is changing.  The compiler will give an error if a c_out or
c_in_out object isn't passed.  You can't enforce a naming convention or
commenting at the point of invocation, at least not everywhere, like where I
work.  So, by writing a function using these objects, it's a guarantee that
anyone who uses my functions has to make it explicit what the effect of
calling my functions is.

----- Original Message -----
From: "Noel Yap" <Noel.Yap_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Thursday, April 24, 2003 4:13 AM
Subject: Re: [boost] Re: class proposal

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