Re: Non-virtual destructors & valarray memory allocation
Michael Hopkins wrote:
Thanks to all for their comments on my original post (over on comp.std.c++ -
I'm not sure if they arrived on comp.lang.c++).
On the first point - many people have suggested composition (or private
inheritance).
All I want to do is add one further member function to std::vector<T>. We
use loops from 1 to n here for their natural fit to mathematical and
statistical thinking, and will continue to do so. Changing this would have
a catastrophic effect in terms of bug creation and headaches when thinking
about and expressing algorithms and will not happen for that reason.
Yikes, perhaps C++ isn't the right language for you then, given the
indexing of arrays.
Luckily, C++ has ample scope for expressing this in a type that we can use
exclusively to solve our problem, so we chose the natural solution - a
member function that apes Fortran behaviour with this.
template <typename T>
class uo_vec : public std::vector<T> // for Unit-Offset vector
{
public:
T& operator()( const iter i )
{
return std::vector<T>::operator[](i - 1);
}
etc..
};
This is also self-documenting when used in code so that people will not
think [0..n-1] when they mean (1..n). It also extends naturally to the
matrix and tensor cases ( i, j ) and ( i, j, k ). Perfect!
Still, it doesn't work on arrays. Have you considered a free function?
Something like:
template <class T>
void uo(T& container, size_t uo)
{
assert(uo > 0u);
return container[uo - 1u];
}
Then:
uo(v, 2)
rather than
v(2)
This has a couple of benefits:
1. It works for built in arrays too.
2. If some library function returns a std::vector, you don't then have
to convert it into a uo_vec.
So with this in mind I want something that behaves like a vector in all
other ways - in particular that the standard library algorithms and
containers will treat exactly like a std::vector<T>.
There's nothing special about std::vector - the interface between
algorithms and containers is the iterator. The STL may be extended with
new container types that are treated equally to the existing ones.
Correct me if I'm wrong (I often am with C++), but wouldn't aggregation or
private inheritance (or any other approach) require the writing of endless
forwarding functions?
With private inheritence, you can use using declaratations. e.g.
template <typename T>
class uo_vec : private std::vector<T> // for Unit-Offset vector
{
typedef std::vector<T> V;
public:
using V::size;
using V::insert;
//etc.
};
And doesn't public inheritance give me exactly what I
need immediately? (And isn't that one of the main reasons for OOD?)
C++ is multi-paradigm - runtime polymorphism is only one of its tricks.
Anyway, that is the motivation for what we currently use quite successfully,
but there is always the nagging doubt that something one day will refer to
it by a base class pointer and then.. Bang. I would prefer not to have this
worry.
As long as they don't delete the base class pointer, there's no problem.
It seems to me that some of the (undoubtedly excellent) thinking behind
giving C++ such increased expressive power over C at so little cost
efficiency-wise has introduced quite a few subtle bugs and gotchas - so that
you can become paranoid in case you break some arcane rule. Think of the
number of style guides and 'gotchas' books that have come out - surely more
than all other languages put together!
What would the practical downside be in giving std::vector & std::valarray
virtual destructors and deriving from them - two bytes per object?
And lots of bytes per instantiation of std::vector in the machine code,
for the RTTI and vtable.
Doesn't
seem like a big disadvantage in these days of Gb of memory and wouldn't the
tradeoff be nice; guaranteed type-safe behaviour in containers. Maybe there
are other design decisions that would have allowed e.g. the avoidance of
schizophrenic polymorphism/'slicing' and other unpleasant C++ artefacts -
maybe again at the cost of a few bytes per object.
If the STL wasn't as efficient as it is (which is still far from
optimal), people would reinvent the wheel more often. As it is, if you
want polymorphic containers, you can wrap the containers with classes
containing the desired virtual functions. You can't do the reverse
though - you couldn't build an efficient non-polymorphic container
library from a polymorphic one.
In engineering generally there has been a strong drive for many years to
design products that are inherently robust against manufacturing,
environment and usage. I don't think anyone could say that about C++ in the
sense of expressing and implementing designs, however enthusiastic they
would rightly be about the complex concepts and algorithms that it is
capable of capturing with such good efficiency. This is a little surprising
when you think of the care that BS took in terms of static type-checking to
produce exactly that result.
Anyway, enough of that.
Question number two was about our need to wrap some C libraries that use
vectors with a few extra elements to hold coded information about length,
orientation etc and extract this info with a defined interface - an early
attempt many years ago to 'objectify' linear algebra objects with C code
that has actually worked very effectively.
We are now interfacing to these 'objects' and their algorithms with a type
that uses std::valarray<T>. I would like to be able to use the member
functions such as min(), max() and others but with some information numbers
'tacked on the end' of a single valarray we can't.
This is not a major headache as e.g. looped min() is not always slower than
member function min() in our tests - it's just about seeing how elegant we
can make the solution. If we could guarantee that the _data_content_ of v1
& v2 below were contiguous (which I suspect we cannot) then we could use v1
for the extra information and treat v2 exactly as a data vector. And when
we need to send it to the C-based functions we could use &v1[0].
class V {
std::valarray<double> v1, v2;
}
valarray generally allocates space for its elements from the freestore,
so the elements of v1 and v2 will be no more contiguous that for any two
random vectors or valarrays from different parts of a program. You may
have some luck with the min_element algorithm, passing in suitable
iterators that don't include the tacked on elements, though you will
lose any SSE type optimizations that might have been used in the
valarray::min implementation.
Tom