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

From: Noel Yap (Noel.Yap_at_[hidden])
Date: 2003-05-04 18:12:20

"Justin M. Lewis" wrote:
> 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.

No, we don't know that; we haven't seen any code that can't be
rewritten.

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

I can't speak for the others.  I don't like the idea because there are
other, IMHO, better ways to program that make clear the intent of a
function.

You seem to be insisting that none of the proposed solutions are
possible in your situation, but you haven't shown a situation where it's
not possible.  Your replies aren't too helpful either without any code
to justify them.

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

Again, I can't speak for the others.  My argument is that I've seen the
problem and it's a sign of poor coding and design -- a band-aid isn't
going to help a hemorrhage.

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

Thanks for the appreciation :-)  I can't understand the arguments
against the proposed solutions (other than some may use non-existent
classes) without seeing code demonstrating they're infeasibility.  Can
you post some, please?

Thanks,
Noel