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

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

Pull from your experience as a programmer and think, you've certainly
encountered places where you're passing polymorphics objects around by
reference or by pointer, calling member functions inside of them that would
be modifying their internal state.  And, while you may not use non-copyable
objects very often, a large part of what I do at work is dependent on
non-copyable objects that I'd like to be able to pass to functions to work
with.

http://www.boost.org/libs/utility/utility.htm#Class_noncopyable

Apparently non-copyable objects are common enough that you have a boost
class dedicated to them.

Or, is no one going to be happy until I write a whole application and post
that on the internet to show the use of my classes?  It seems a bit
ridiculous that what I'm posting can't be looked at and figured out.  I
mean, most of my C++ books give trivial examples that make little sense that
make the point clear, and I was able to get the point, without having to
nitpick the details.

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

> 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
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>