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

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-05-04 12:21:22

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();
   }

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