Re: The best way to retrieve a returned value... by const reference?
On Jun 1, 1:52 pm, "Niels Dekker - no return address"
<inva...@this.is.invalid> wrote:
Virtual functions are here to stay, and I don't think it's "in
general" bad practice to return an object "by-value" whose
type has virtual functions.
James Kanze wrote:
"In general", a type which is part of an inheritance hierarchy
shouldn't support copy and assignment.
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.
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. (And
since copy was blocked in the base class, it would require extra
effort to unblock it.)
Most of the time, objects which support inheritance will
have identity. (Do note the extensive qualifiers in the
above.
I'm sorry I don't really understand the above. Please explain!
In theory, polymorphism and identity are two separate,
orthogonal concepts, but in practice, polymorphism tends to be
used principally on classes with identity. At least in my
experience---it's certainly not a rigid rule.
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.
--
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