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

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-05-04 15:52:38

Of course I am addressing the specifics of the example!  That's
what examples are for -- to make abstract ideas specific enough
to be addressed in detail.

And you are missing my point, which is that in every example you
have given of a situation that calls for an out parameter there
appears to be an an alternative, and superior, design that avoids
using an out parameter.  So why do we need a special facility to
support an inferior design style?

On Sunday, May 4, 2003, at 14:31 America/Denver, Justin M. Lewis wrote:
> From: "Gregory Colvin" <gregory.colvin_at_[hidden]>
>
>> This example seems rather contrived, and necessary only because of
>> horrendous interface provided by CNonCopyable.  There is no reason
>> I can see why ReadFile() should copy the file into a private buffer,
>> to be used later by PrintFile().  Better that ReadFile() return a
>> new container, to be passed in to PrintContainer().  So I assume the
>> point of the example is that your are stuck with CNonCopyable and
>> trying to make the best of a bad situation.
>>
>> CNonCopyable nc;
>> SetupNCObj(out(nc));
>> ReadFileAndPrint(in_out(nc));
>> nc.Print();
>> CleanupNCObj(in_out(nc));
>>
>> In which case why not:
>>
>>    struct FileWrapper : CNonCopyable {
>>      FileWrapper(const string &fname) { SetFName(fname), OpenFile(); }
>>      ~FileWrapper() { CloseFile(); }
>>    };
>>
>>    void ReadFileAndPrint(const string &fname) {
>>      FileWrapper(fname) f;
>>      f.ReadFile();
>>      f.Print();
>>    }
>>
>
> Again, you're addressing the specifics of an example, rather than the 
> idea
> itself.  You can see the point, and you have to realize that in real 
> life,
> situations come up where you have an object that can't be copied, but 
> you
> still want to use, and pass around to functions.
>
>
>
>> So we are back where we started -- I can see some use to this
>> proposal for writing wrappers for existing interfaces that depend
>> heavily on out and in/out parameters, but am not convinced it is
>> the best way to write such wrappers, and can't see it's value for
>> new designs that can just avoid such parameters.
>>
>> On Sunday, May 4, 2003, at 04:44 America/Denver, Justin M. Lewis 
>> wrote:
>>
>>> This is what I came up with real quick.
>>>
>>> http://groups.yahoo.com/group/boost/files/in_out/test1/
>>>
>>>
>>> ----- Original Message -----
>>> From: "Gregory Colvin" <gregory.colvin_at_[hidden]>
>>> To: "Boost mailing list" <boost_at_[hidden]>
>>> Sent: Saturday, May 03, 2003 9:37 PM
>>> Subject: Re: [boost] Re: in/out parameters, 
>>> codingstylesandmaintenance
>>>
>>>
>>>> Code, please.
>>>>
>>>> On Saturday, May 3, 2003, at 22:18 America/Denver, Justin M. Lewis
>>>> wrote:
>>>>
>>>>> Or, how about polymorphic types, where you can't simply create the
>>>>> object
>>>>> internally in the function, where you HAVE to deal with what's 
>>>>> passed
>>>>> in in
>>>>> one way or another.
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Gregory Colvin" <gregory.colvin_at_[hidden]>
>>>>> To: "Boost mailing list" <boost_at_[hidden]>
>>>>> Sent: Saturday, May 03, 2003 9:15 PM
>>>>> Subject: Re: [boost] Re: in/out parameters,
>>>>> codingstylesandmaintenance
>>>>>
>>>>>
>>>>>>
>>>>>> On Saturday, May 3, 2003, at 22:03 America/Denver, Noel Yap wrote:
>>>>>>
>>>>>>> Gregory Colvin wrote:
>>>>>>>> Anyway, I jumped into this thread mainly to opine that Noel's
>>>>>>>> suggestions
>>>>>>>> were not, so far as I could see, any better than your proposal,
>>>>>>>> not
>>>>>>>> to
>>>>>>>> rehash what we have already discussed.
>>>>>>>
>>>>>>> I think that if ref<> were used instead of dumb_ptr<> in my
>>>>>>> previous
>>>>>>> posts, it's a little better since, IIRC, ref<> already exists.
>>>>>>
>>>>>> A little.  But so far Justin's examples don't require it.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Unsubscribe & other changes:
>>>>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Unsubscribe & other changes:
>>>>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>>>
>>>> _______________________________________________
>>>> Unsubscribe & other changes:
>>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>>>
>>>
>>> _______________________________________________
>>> Unsubscribe & other changes:
>>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>> _______________________________________________
>> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost