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

From: Justin M. Lewis (boost_at_[hidden])
Date: 2003-05-04 17:25:07

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

> On Sunday, May 4, 2003, at 14:59 America/Denver, Justin M. Lewis wrote:
> > 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.
>
> Yes, I've done that a lot when dealing with COM interfaces.  In my
> experience your proposal would not have made that job any easier,
> as I would have had to write wrappers for every method of every
> interface, and I can't recall a single defect in that code caused
> by failing to know which parameters were out parameters anyway, so
> why bother?  Your mileage may vary.
>
> > 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.
>
> So if you really need to do that, just do it.  I still don't see
> much value in cluttering up the code with in, out, and in_out.
>
> > 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.
>
> So far I've looked at it, figured it out, and not liked it.
>
> > 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.
>
> What you call nitpicking Boost calls rigorous review.  It's a
> very hot kitchen in here, staffed by some of the world's best
> chefs, who keep their knives very sharp.
>

That's not rigorous review, when you obviously KNOW the point, then ignore
it to nitpick the example, which was used only to show the basic use, not
give a real world example.  You know I could come through, and make the
example more complex, and give my classes more members, and make my
functions do more so that their existence would be justified.  You know in
the case of the non-copyable object that cases exist where you have a
non-copyable object that you pass around and modify.

Basically, you don't like the idea, that's fine.  You wouldn't use it
yourself, that's fine.  But, nitpicking the examples is hardly constructive.
Attack the idea, that's really the point of all of this.  You can say you
see no use for it.  When I was doing COM I didn't either.  It wasn't until I
was dealing with very large projects with legacy code that had been around
for years that I got frustrated with this problem.

Basically your argument is, you've never experienced the problem, so it must
not exist.  I can tell you first hand, the problem does exist, and there are
people who have to deal with it on a daily basis.  This is my solution to
the problem, if there's a better solution, I'm open to hearing about it.

I have appreciated Noel's comments very much in that aspect, and the others,
who have suggested alternatives.  But, so far, the alternatives, I think,
fall short of the intent of my proposal.

> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>