efficiency of a non-polymorphic inheritence

[toton]

Hi,
I am inheriting a vector<Point> class as a PointVector
non-polymorphically, to add several additional functionalities to it.
I know the dangers of inheriting a container class, as it doesn't
have a virtual destructor from a previous post by me, and thus it is
designed as a safe way.
As the PointVector is non polymorphic (and its runtime typeid also
shows the same), can I assume it is as efficient as a typedef to
vector<Point> ? i.e no vtable, and no additional function call overhead
?
As this class is going to be used for some of my critical computation,
I need to avoid any such kind of overhead.

Thanks
abir

 

[Victor Bazarov]

I am inheriting a vector<Point> class as a PointVector
[...]
As this class is going to be used for some of my critical computation,
I need to avoid any such kind of overhead.

You can assume all you want, but when it comes to performance, you need
to measure first and draw conclusions next. Optimize what is proven
unoptimal [by measuring], not what somebody might think is unoptimal.

There are many things that improve the performance of a program that
makes use of 'vector', including but not limited to compiler switches,
avoiding unnecessary copying, processor cache management... I assure
you, virtual function dispatch mechanism is probably going to be the
least of your worries, when you're done implementing all functionality.

V

 

[Nindi]

Hi,
I am inheriting a vector<Point> class as a PointVector
non-polymorphically, to add several additional functionalities to it.
I know the dangers of inheriting a container class, as it doesn't
have a virtual destructor from a previous post by me, and thus it is
designed as a safe way.
As the PointVector is non polymorphic (and its runtime typeid also
shows the same), can I assume it is as efficient as a typedef to
vector<Point> ? i.e no vtable, and no additional function call overhead
?
As this class is going to be used for some of my critical computation,
I need to avoid any such kind of overhead.

Thanks
abir

You will have to write new constructors, so maybe there will be an
overhead when calling the base class constructors.
Assignment operator is not inheritable, so this will have to be
re-coded.

I am also interested in answers to your question.

Why would you not use composition ?

That way you could possibly change the internal container, the vector,
in the future much more easily.

I'll be wathcing this space .

N

 

[Nindi]

You will have to write new constructors, so maybe there will be an
overhead when calling the base class constructors.
Assignment operator is not inheritable, so this will have to be
re-coded.

I am also interested in answers to your question.

Why would you not use composition ?

That way you could possibly change the internal container, the vector,
in the future much more easily.

I'll be wathcing this space .

If you had a pimpl to your vector and all your pimpl methods were
inlined then there should be no overhead right ?

 

[Earl Purple]

If OP wants to use it as a vector but also have additional
functionality, the simplest thing is to write a number of
free-functions that work with the public interface of vector, as that's
pretty much what he's doing anyway.

The existing algorithms in the standard library already do exactly
that, except they are often generic enough to work with the vector's
iterators.

 

[Nindi]

If OP wants to use it as a vector but also have additional
functionality, the simplest thing is to write a number of
free-functions that work with the public interface of vector, as that's
pretty much what he's doing anyway.

The existing algorithms in the standard library already do exactly
that, except they are often generic enough to work with the vector's
iterators.

That apeals alot more to me, for one its simpler !!!! and with
hindsight its more obvious.
But I would still typedef it.

 

[toton]

You will have to write new constructors, so maybe there will be an
overhead when calling the base class constructors.
Assignment operator is not inheritable, so this will have to be
re-coded.

I don't need container assignment. Constructor is one time call. All I
need is a frequent access (either through iterator or direct indexing)
, and add & remove elements (for which I want additional methods rather
than push_back ).

I am also interested in answers to your question.

Why would you not use composition ?

Oh! Absolutely possible. Only it is tedious, and need to forward each
call ( and hence may be some overhead).
Check a previous post by me and expert answers by Kai-Uwe Bux. I
preferred his over Pete Becker's .
http://groups.google.com/group/comp...6c96?lnk=gst&q=toton&rnum=21#55ae69eaa3d56c96