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

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-04 15:31:35

----- Original Message -----
From: "Gregory Colvin" <gregory.colvin_at_[hidden]>
To: "Boost mailing list" <boost_at_[hidden]>
Sent: Sunday, May 04, 2003 10:21 AM
Subject: Re: [boost] Re: in/out parameters, codingstylesandmaintenance

> 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
>