Re: Non-virtual destructors & valarray memory allocation
Michael Hopkins wrote:
Hi all
A couple of questions that are influencing the design of some classes.
1) Why were the std:: library containers not given virtual destructors - is
this a feature or an oversight?
Feature. They don't need them as they have no other virtual methods so
how can you override any of their functionality anyway?
We would like to derive publicly from them in a couple of cases and now have
to be more disciplined than we should need to be about how we use those
types.
There is no need to derive publicly from them. If you want to add extra
functionality then either:
1. create free-functions that take the collections as parameters After
all, you are only going to use their public methods (there are no
protected ones and you won't have access to the private ones anyway).
2. Create a class that uses aggregation, i.e. it contains the
collection you want and has extra functions. You can then allow users
to call all the original functions either by implementing them
yourself, providing an implicit conversion or (preferred) overloading
operator-> (operator. cannot be overloaded). The last of these will
automatically bring in all the behaviour you want without the dangers
of implicit conversion.
2) Is there any way of declaring e.g. two valarray<double> so that they are
guaranteed to be contiguous in memory? i.e.
class V {
std::valarray<double> v1, v2;
}
class V
{
std::valarray<double> v[2];
}
The two valarrays will be in contiguous memory. That doesn't mean the
values they represent will be. They almost certainly won't be. If that
is what you want then no - you'll have to copy them into a big valarray
and then slice it to create the 2 smaller ones (well the 2 slices
anyway).
TIA and please CC replies to this address
No., If you don't have time to read the group, the group doesn't have
time for you either.
---
[ 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 ]