Re: Non-virtual destructors & valarray memory allocation
Sometimes the point of deriving from a class is only to extend.
At least one popular language even uses the keyword "extends" to
designate class derivation.
That popular language also has every class deriving from an Object
class, and doesn't have destructors at all, so no need to worry about
virtual ones. Nor does it support free-functions although you can
create a class simply to provide functions. It does have a "final"
keyword though.
That said the lack of virtual destructors is only a problem if
dynamically allocated instances are destroyed polymorphically, which in
practice isn't much of a problem,
Probably not with string or vector, possibly more of a problem with
map, but you can't be sure.
Consider constructors, notational consistency, introduction of virtual
member functions, interfaces, memory management, you name it.
constructors: Easy. Suppose I want to be able to create a vector from a
static array. Let's create a function make_vector.
template < typename T, size_t N >
std::vector< T > make_vector( const T (&arr)[N] )
{
return std::vector( arr, arr+N );
}
std::vector< int > = make_vector( { 1, 2, 3, 4, 5 } );
(I think that should compile anyway)
notional consistency: as I've created a vector and not a different
class I have all the functionality of vector.
Ok, I don't have any polymorphism here - if I'm going down that path
and creating a big hierarchy, then I will create a class that contains
a vector and possibly allow some methods like push_back(), begin(),
end(), empty() and size().
Some standard library classes have protected members.
Some standard library classes are meant to be derived from like
basic_streambuf. Are there any that have protected members and no
virtual methods and no virtual destructor?
Regarding the destruction issue, what are smart pointers for?
Essentially a smart pointer puts in place, or can put in place, the
equivalent of a virtual destructor.
Ok, let's see how. You have an API that takes shared_ptr< map< X , Y >
but I don't have a map, I have a class derived from map. So I have to stick in some deleter, I presume. I'm not that familiar with the inner workings of boost deleter and what happens to it when you cast. (If the deleter derives from an "untyped" base (untyped on pointer type) and stores the pointer it is going to delete until the time comes then obviously it is simple enough. If the standard deleter does that I don't even need a custom one).
Is there a standard policy with regards to the behaviour of
tr1::shared_ptr deleters? If so, what is it?
Summing up, when deriving from a standard library class would be in
order except for the lack of virtual destructor, just derive, but don't
destroy polymorphically -- use smart pointers if that's an issue.
Yes obviously. But it is probably still wrong to derive from concrete
classes most of the time.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]