Re: A deque containing different types of objects (with a common
base class)
Kai-Uwe Bux wrote:
Not quite: shared_ptr<> does not require the base type to have a virtual
destructor. It will invoke the correct destructor for the derived type.
Let's see if I understand that. If you do this:
shared_ptr<BaseClass> ptr = new DerivedClass;
then 'ptr' will contain a BaseClass-type pointer (which points to an
object of type DerivedClass) and, I assume, a pointer to the destructor
function of DerivedClass (as a void(*)() function pointer)? (One could
wonder why waste memory to do this since that's exactly what virtual
functions are for, and if BaseClass does have a virtual destructor then
the pointer will be basically a useless waste of memory, but that's
besides the point.)
Since shared_ptr<BaseClass> only knows the BaseClass type when it's
destroyed (I assume that it doesn't waste even more memory creating a
virtual "destructor object" of a sort which destroys the DerivedClass
object using the proper pointer type) then how does it actually call the
DerivedClass destructor, given that it only has a BaseClass type pointer
to the object? It cannot cast the pointer to DerivedClass since it
doesn't know DerivedClass when the shared_ptr is destroyed. The only
standard-compliant way of calling the DerivedClass destructor is to have
a DerivedClass pointer.
Calling the destructor function giving it the raw BaseClass pointer
would obviously be wrong (because it's not guaranteed that a pointer of
type BaseClass will be unchanged when it's cast to DerivedClass, and
thus if you call the DerivedClass destructor using an uncasted BaseClass
pointer it's perfectly possible for the pointer to point to the wrong
place). So how?
Please don't take this as arguing. I'm not arguing. I'm honestly
interested in knowing how it's done.
I realzed shortly after I posted
that one can do without for the container type as long as there is no need
to support incomplete types.
STL containers cannot be instantiated with incomplete types anyways,
so it's not a big deal if this special deque couldn't be either.
As for the copying function, I said in my original post that functions
requiring copying or assignment (such as erase()) could simply not be
implemented.
And I showed that they can.
The whole purpose of this idea was to save memory, not to waste it.
Your choice. Your container then is also not copy-constructible
Big deal? I have seldom needed the copy constructor of any STL container.
Sure, it would not have *all* the properties of an STL container, but
many of them could be implemented.
and cannot
be based on a vector (because of reallocation).
That's exactly why I wrote about deque in the first place. I don't see
what's the big deal with that.
As for "you are using premature optimization", if my concern was not
memory usage then I would use some std::vector<SmartPointer<Base> > and
not worry about the memory usage. However, sometimes memory-efficient
data containers are useful. It's not "premature optimization" to use
one, given that it's easy to use, abstract, and has been thoroughly
tested.
Using it makes your code brittle because you have some alignment and size
requirements that the container imposes on the client code. One could
(should?) put in some compile time checks to catch violations. That may
require some serious template magic or be impossible (e.g., I don't see off
hand a compile time check for alignment requirements). This case is no
exception to the rule that the optimization is premature as long as it has
not been proved to be needed.
That argument doesn't make too much sense.
Some STL containers impose some rules on their elements. For example,
a std::set requires that the elements are comparable and that the
comparison of two elements always gives the same result. No big deal,
but it's still an additional requirement compared to eg. a std::vector.
Is it "premature optimization" to use std::set?