|
Boost : |
From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-05-04 17:35:43
"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?
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk