Re: Virtual bases and default move and swap functions [n2583, n2584]
On May 22, 12:38 pm, Seungbeom Kim <musip...@bawi.org> wrote:
Richard Smith wrote:
In a virtual inheritance hierarchy, the implicitly-declared assignment
operator is allowed to assign the base class multiple times
[[class.copy] 12.8/13]:
[ example snipped ]
Generally, this is not a problem, as it is fairly unusual to store
data in virtual bases, [...]
Is it really? I thought the point of virtual inheritance was to prevent
having separate copies of the data members from the same base class;
without any data members in the base, making the base virtual or
non-virtual wouldn't make much difference. Am I wrong?
Well, I'd say more generally, the point of virtual inheritance is to
avoid multiple copies of the base class. Sometimes you want to do
that to avoid having multiple copies of the data members of the base
class, but that's not the only reason. Mixins are another common
example, and (in my personal experience, ymmv) this is the more common
reason.
struct interface {
virtual void f() = 0;
virtual void g() = 0;
};
struct mixin : public virtual interface {
virtual void f() { ... }
};
struct impl : public virtual interface, private mixin {
virtual void g() { ... }
};
Remove the virtual inheritance, and you have a problem: impl is still
abstract because f() is pure virtual in one copy of interface, and a
using declaration will not fix this.
Another common situation is when you have extensive Java-like
interface inheritance:
class DataSource {};
class SeekableDataSource
: public virtual DataSource {};
class NetworkDataSource
: public virtual DataSource {};
class MyDataSource
: public virtual SeekableDataSource,
public virtual NetworkDataSource {};
The virtual inheritance ensures that there is an unambiguous
conversion from MyDataSource* to DataSource*.
And this will generally double-assign the base class, V, because
A::operator= will assign it, and then B::operator= will do it again.
However, for most classes, the double assignment is safe -- it is
merely a slight inefficiency.
One way to prevent double assignment is, implementing separate
assignments by hand:
Sure, you can avoid it by writing things by hand. However for the
assignment operator, it's generally not worth the hassle as multiple
assignment doesn't usually hurt. And so a lot of the time the default
generated copy assignment operator is fine.
In today's language, objects with odd copying semantics are rare, and
it is only when these are involved that you see problems. Hopefully
the addition of rvalue references in C++0x will make them even rarer
as a move constructor, T::T(T&&), can be used in place of a moving
copy constructor, T::T(T&), and similarly for assignment operators.
So I don't have a problem with the copy assignment operator, as it's
rarely a problem today, and is likely to be less of a problem in the
future.
The same is not the case with move assignment operators and swap
functions as the proposed default implementation will break with
"normal" classes, not just with classes with peculiar semantics.
--
Richard Smith
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]