From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2003-05-04 16:32:14
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.