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

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

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

> "Justin M. Lewis" wrote:
> > > > This is what I came up with real quick.
> > > >
> > > > http://groups.yahoo.com/group/boost/files/in_out/test1/
> > >
> > > I didn't see:
> > >
> > > void test_out2(c_out<int> i) // this shouldn't compile
> > > {
> > > int& j = i.get_ref( i );
> > >         ++j; // using existing state of input
> > > }
> > >
> > > void test_in( c_in< int > i_ ) // this shouldn't compile
> > > {
> > > int& i = i_.get_ref( i );
> > > ++i; // changing existing state of input
> > > }
> > >
> >
> > If that's what you've been thinking this whole time, then you've
completely
> > missed the point.  It's up to the programmer to properly uses these
classes.
> > If they don't, well, what can anyone do about that?
>
> My point is that if those tests aren't satisfied, the proposed classes
> don't do what they advertise.  Let's say there's the code:
>
>   void f( c_in< int > i_ )
>   {
>     // implementation of f evolves into a really big confusing mess
>   }
>
> then one day someone decides, without much thought:
>
>     ++i_;
>
> I think the compiler should be able to catch this.  Don't you?
>

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.

That's a good thing though, all that maintenance keeps us employed.

> The out parameter shouldn't be so bad in most situations aside from the
> false advertisement since an out parameter acting like an in/out
> parameter is harmless in most cases.
>

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