Re: The best way to retrieve a returned value... by const reference?
On Jun 3, 10:54 pm, "Niels Dekker - no reply address"
<inva...@this.is.invalid> wrote:
Thanks, James. But personally I think it's okay for a "leaf"
of an inheritance hierarchy (a type that should be considered
"sealed") to be CopyConstructible.
James Kanze wrote:
Most of the time, it probably doesn't hurt, if the type doesn't
have identity. But usually, there's no point in it, since
client code doesn't normally use the leaf classes anyway.
As a client, I quite often use leaf classes from other
libraries (notably Qt). I'm surprised that doing so might not
be normal.
I'm not familiar with Qt, but in the GUI work I've done (Java
Swing), I generally derived from the library classes, and passed
instances of derived classes back to the library. It was the
library which used the objects, so the shoe was on the other
foot. But you're right that in this case, your code is often
aware of the actual leaf class (and in a number of cases, the
library class can be used directly as a leaf---but the library
itself doesn't know that the type it's dealing with is actually
the final type).
On the other hand, of course, GUI classes almost always have
identity, and aren't copiable, so the question doesn't arise.
(And since copy was blocked in the base class, it would
require extra effort to unblock it.)
Assuming that you put extra effort to block copying in the
base class, of course... An abstract base class isn't
CopyConstructible, but a derived class may still get a
compiler-generated copy-constructor "for free".
Most of the time, my abstract base class will simply derive from
Gabi::Interface, which takes care of some of the more mundane
details, like ensuring that the destructor is virtual. And
making the object uncopiable:-).
There are certainly exceptions, and not a few.)
Like std::exception? ;-)
Yes, and you can see the problems that can sometimes cause.
You can't pass an exception into a function for that
function to throw, because the thrown type is the static
type. The reason, of course, why the static type is thrown,
rather than the dynamic type, is that the compiler must
allocate memory and generate a call to the copy constructor;
if exceptions weren't to be copied, then throw could easily
use the dynamic type.
Okay. But still I'm not particularly happy about
std::exception being CopyConstructible. Because it's mostly
used as a base class anyway. (I would have liked it to be an
abstract base class.) And because the effect of copying an
std::exception is rather unclear. Fortunately it looks like
this effect will be clarified, by the resolution of an LWG
issue, submitted by Martin Sebor: "result of what()
implementation-defined"http://home.roadrunner.com/~hinnant/issue_review/l=
wg-active.html#973
The problem of copying is a bit awkward in the case of
exceptions. But copy you must, given the way the C++ object
model works. (On the other hand, I don't see any value in
supporting assignment.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34