Boost logo

Boost :

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-04-23 23:09:51


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.

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.

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.

----- Original Message -----
From: "Noel Yap" <Noel.Yap_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Wednesday, April 23, 2003 6:32 PM
Subject: Re: [boost] Re: class proposal

> "Justin M. Lewis" wrote:
> >
> > Yes, it is better.
> >
> > The first example has the problem of, you still have to go look up the
> > function to see if it's actually changing anything, or if it's taking
the
> > param in, reading teh value, then modifying based on what was read.
>
> Then how about:
>
> boost::tuple< boost::shared_ptr< LargeObject > > result = f(
> largeObjectSharedPtr );
>
> > The second example has the problem of copying a potentially large
object,
> > and it doesn't allow for in/out params.
>
> I'm still not convinced that in/out parameters are necessary.
>
> Noel
> --
> NOTICE: If received in error, please destroy and notify sender. Sender
> does not waive confidentiality or privilege, and use is prohibited.
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk