Re: [boost] Re: class proposal

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

----- 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.
>

I think most COM objects are written in C++.  I should have been more
specific here, if you're looking at ActiveX objects, in/out params are used
all over the place.  Each function returns an HRESULT, iirc, any data you
want returned has to be returned in a param.

> > 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, it's not either pass in a whole object or pass in a pointer, you're
forgetting references.  This new class takes in a reference, and stores
that.  It doesn't do anything with pointers.

> > 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
>

And, again, returning an object isn't always desirable, you could be copying
large objects for no reason.  You may not call a copy constructor, but an =
operator is being used.

_______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>