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

From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-05-04 06:58:42

"Justin M. Lewis" wrote:
> > > > One more time:
> > > >
> > > >   void f( dumb_ptr< T const > in_ );
> > > >   void f( dumb_ptr< T > inOut_ );
> > > >   dumb_ptr< T > f(); // out
> > > >
> > > >   int i = 5;
> > > >   dumb_ptr< int const > in( &i );
> > > >   dumb_ptr< int > inOut( &i );
> > > >   dumb_ptr< int > out = f();
> > > >
> > > >   f( in );
> > > >   f( inOut );
> > > >
> > > > Exactly what's confusing you with the above?
> >
> > No answer to my question?  I'm really trying to understand why you're so
> > adamant against using one template class in favor of two or three.  Can
> > you answer this question, please?
> >
> 
> Why not do things like that?  Well, for 1, you still have no concept of out
> params there.

Other than syntax, what's the difference between:

  dumb_ptr< int > out = f();

and:

  int out;
  f( c_out( out ) );

>  2, you've created 2 pointers to i, rather than just putting
> it all nicely inline.

OK, nicely inlined:

  int i;
  f( dumb_ptr< int >( &i ) ); // in/out parameter
  f( dumb_ptr< int const >( &i ) ); // in parameter
  dumb_ptr< int >( &i ) = f(); // out parameter

>  And, you're still using pointers, not references.

Using references:

  int i;
  f( dumb_ref< int >( i ) ); // in/out parameter
  f( dumb_ref< int const >( i ) ); // in parameter
  dumb_ptr< int >( i ) = f(); // out parameter

Seriously, if you start thinking of references as implicitly
dereferenced pointers, all these examples would be much less verbose.

Isn't the entire point of your proposal to have a (or any) syntactic
difference among in parameters, out parameters, and in/out parameters? 
Don't dumb_ptr<> and dumb_ref<> do that?

Also, I think one reason you're having trouble getting this past the
boost developers is that many progammers are happy to use pointers to
signal that a variable may change.  Yes, this has the downside that the
parameter may be NULL, but it seems many are willing to take that risk
rather than using another syntax or they have ways of dealing with that
risk.

Noel