469,894 Members | 2,209 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,894 developers. It's quick & easy.

efficiency of a non-polymorphic inheritence

Hi,
I am inheriting a vector<Pointclass 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

Nov 14 '06 #1
6 1309
toton wrote:
I am inheriting a vector<Pointclass 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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Nov 14 '06 #2

toton wrote:
Hi,
I am inheriting a vector<Pointclass 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

Nov 14 '06 #3

Nindi wrote:
toton wrote:
Hi,
I am inheriting a vector<Pointclass 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 .

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

Nov 14 '06 #4
Nindi wrote:
toton wrote:
Hi,
I am inheriting a vector<Pointclass 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
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.

Nov 14 '06 #5

Earl Purple wrote:
Nindi wrote:
toton wrote:
Hi,
I am inheriting a vector<Pointclass 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
>

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.

Nov 14 '06 #6

Nindi wrote:
toton wrote:
Hi,
I am inheriting a vector<Pointclass 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 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....ae69eaa3d56c96
That way you could possibly change the internal container, the vector,
in the future much more easily.

I'll be wathcing this space .
Thanks
N
Nov 15 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

24 posts views Thread by JKop | last post: by
9 posts views Thread by Peng Jian | last post: by
335 posts views Thread by extrudedaluminiu | last post: by
83 posts views Thread by Licheng Fang | last post: by
2 posts views Thread by yicong | last post: by
reply views Thread by Laurent Deniau | last post: by
5 posts views Thread by Lars | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.