Re: [boost] Re: in/out parameters, codingstylesandmaintenance

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-04 22:40:58

----- Original Message ----- 
From: "Noel Yap" <Noel.Yap_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Sunday, May 04, 2003 7:36 PM
Subject: Re: [boost] Re: in/out parameters, codingstylesandmaintenance

> "Justin M. Lewis" wrote:
> > I have thought about that, yes.  And, as these were first made, I'll go
> > through their history again.  Originally it was only for out values,
that
> > was my original use.  I had discussions with some people on IRC, someone
> > there split the code into 2 classes, out and in_out, and on top of that,
he
> > made them different.  out params did NOT allow you access to the
internal
> > object at all, it ONLY gave you a = operator so you could assign the
> > internal object something.  Both classes at one point had asserts to
make
> > sure the internal data was modified in some way before the destruction
of
> > the out or in_out object.  I found that to be annoying, because I may
not
> > simply want to assign a value to an out object.  I may want to use one
of
> > its member functions to modify it, or initialize it.  So, I gave both
> > classes cast operators, so I could get the internal data, then removed
the
> > assert, because it was in the way now.  Now, you MIGHT be able to set
these
> > classes up in such a way that you can access the member functions of an
out
> > object, but, not get a reference to it still, so you can't just grab it
and
> > start screwing with it however you want.  The problem is, you still have
no
> > way of determining which member functions inside the object depend on
the
> > current state of the object, and which ones don't.  So, ultimately, no
> > matter how you do this, some of the burden of not breaking the system
falls
> > on the programmer.
>
> OK.  What happens if we turn this around?
>
> We're pretty sure we can't have pure out parameters (at least not
> without a lot of pain).  Then again, we're almost certain we can have
> pure in parameters.  So, why not use in_out<> for both out (since pure
> out parameters don't exist in C++ anyway) and in/out parameters, and
> in<> for pure in parameters?

I disagree, my original use of this idea was for an out param.  Initially I
had no concept of in_out params, it wasn't until I started talking about the
idea with others that in_out was introduced.

>
> > That's a good thing though, all that maintenance keeps us employed.
>
> <sarcasm tone="friendly">
> Ahh, yes, the worthy goal of staying employed rather than adding value
> :-)
> </sarcasm>
>
> Noel
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>