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

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-05-03 19:53:02

On Saturday, May 3, 2003, at 18:07 America/Denver, Justin M. Lewis 
wrote:
> From: "Gregory Colvin" <gregory.colvin_at_[hidden]>
>> On Saturday, May 3, 2003, at 17:52 America/Denver, Noel Yap wrote:
>>> Gregory Colvin wrote:
>>>>
>>>> On Saturday, May 3, 2003, at 17:13 America/Denver, Noel Yap wrote:
>>>>
>>>>> Noel Yap wrote:
>>>>>>   std::auto_ptr< T > t( new T() );
>>>>>>   f( boost::dumb_ptr< T >( t.get() ); // clearly an in/out 
>>>>>> parameter
>>>>>
>>>>> Or if you don't want to dynamically allocate t:
>>>>>
>>>>>   T t;
>>>>>   f( boost::dumb_ptr< T >( &t ) ); // clearly an in/out parameter
>>>>>
>>>>>   static T t;
>>>>>   f( boost::dumb_ptr< T >( &t ) ); // clearly an in/out parameter
>>>>
>>>> Not so clear -- it depends on whether f() cares about the initial
>>>> value of t.
>>>
>>> So you're saying the parameter can be an out-only parameter?  If so,
>>> for
>>> out parameters, use:
>>>
>>>   boost::dumb_ptr< T > f();
>>>   t = f();
>>>
>>> IMHO, the intent is much more clear than:
>>>
>>>   f( out< T > t );
>>>   f( out< T >( t ) );
>>
>> Not to me it isn't.
>>
>>>>  Also, not in my opinion any more clear than:
>>>>
>>>>     f(&t);
>>>
>>> I agree, but the OP doesn't like raw pointers from what I've gathered
>>> from the thread.
>>
>> Who is OP?
>>
>> Anyway, I dislike out parameters more than I do raw pointers.
>>
> That doesn't really make sense, since out params aren't always 
> avoidable,
> nor are in_out params.  I mean, disliking them aside, they're necessary
> sometimes.

Agreed.  And when they are necessary I am happy enough with
pointers -- or at least my unhappiness is not reduced by
any of various wrappers proposed here.