Re: [boost] in/out parameters, coding styles and maintenanc

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-04-25 02:41:38

Ok
http://groups.yahoo.com/group/boost/files/in_out/

There's the link to the current versions of these classes.  At one point in
time the c_out and c_in_out were different.  c_out didn't used to have a
cast operator, and both classes used to keep an extra state to make sure
something had been assigned to the object, and would assert on destruction
if nothing had been assigned.

This has gone through a little evolution since I first did it.  My original
class was called just CRetVal.  I discussed the whole idea with people on
the Undernet #c++ channel, and, someone there submitted 2 classes, out and
in_out, in almost the state I described above.  I made the constructors
explicit, and changed the names of the classes to c_out and c_in_out, to
clear the way for helper functions named out and in_out.  Then I removed the
checks, as I found them annoying, and added a cast operator to c_out, since
you may not just want to assign something to the object, you may want to
call a member function of the object.

Anyway, that's the quick history of the evolution that brought us to the
current files there.

Justin

----- Original Message -----
From: "Erdei Andras" <ccg_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, April 24, 2003 11:53 PM
Subject: Re: [boost] in/out parameters, coding styles and maintenanc

>
> On Thu, 24 Apr 2003, Augustus Saunders wrote:
>
> > 1) We normally pay a lot of attention to safety of usage,
> clarity of
> > intent, confusion from subtle semantics etc in our
> discussions.
> > Sometimes we might even belabour the point (though I think
> it's
> > healthy).  This question goes to the library writers here.
>  Would you
> > replace:
> <snip>
>
> generally not. when i was new to c++, this was a thing that
> really bothered me, but it turned out that on well designed
> interfaces it's quite obvious which args are in, and which ones
> are in-out.
>
> otoh atm i'm using a badly designed api, where half the
> parameters
> are in-out (embedded system, no exception-handling, all return
> values are error codes), and it isn't obvious at all which half.
>
> it's not that problematic when writing new code, but when
> reading
> or debugging code already writen it's a real pain in the lower
> region.
>
> so the proposed original usage (using the helper class to turn
> badly designed legacy code into something comprehensible in a
> fairly painful, mechanical way) seems very appealing to me.
>
> another usage i can imagine is function overloads:
>
> bool f( T const & ) ;
> bool f( in_out< T > & ) ;
>
> somethimes you only want to know if a computation is doable,
> and sometimes you also need the result. this can be better than
> having two functions with different names -- goof names are hard
> to come by.
>
> but, as someone suggested, only experience call tell whether
> this
> is really usable; someone brave enough please try it, and let us
> know after a few months whether it works :O)
>
> > Lastly, if the proposed implementation has been posted, I
> missed it,
> > so can somebody post it or a link again?
>
> i don't remember any implementation, but just off the top of
> my head:
>
>   template < typename value_type_ >
> struct in_out_arg
>   {
>     typedef value_type_ value_type ;
>     value_type & value ;
>     explicit in_out_arg( value_type & value ) : value( value
> ) {}
> operator value_type & () { return value ; } ;
>   } ;
>
>   template < typename value_type >
> in_out_arg< value_type >
> in_out( value_type & value )
>   {
>     return in_out_arg< value_type >( value ) ;
>   }
>
>   bool
> f( in_out_arg< int > i )
>   {
>   i = 1 ;
>   ++i ;
>   return false ;
>   }
>
>
> int i = 0 ;
> f( in_out( i ) ) ;
>
>
> br,
> andras
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>