.moderated cross post!!! Implementing functional paradigm with C++

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Virtual functions negatively affect performance in 3 main ways:
1) The constructor of an object containing virtual functions must
initialize the vptr table, which is the table of pointers to its member
functions.
2) Virtual functions are called using pointer indirection, which
results in a few extra instructions per method invocation as compared
to a non-virtual method invocation.

Those type of argumentations usually omit to consider the point that if you
need the "virtuality" in some case and you don't want to use a virtual
functions you must use some other mechanism... and with a great probability
his cost will not be zero.

And if you don't need it, just don't use it in that case. There not exist
such rule as "in any project, all class must have virtual functions, or
none of them".

 

[Hans]

<Is action table not just another name for vtable, i.e. an array of
function pointers? If so, the performance ought to be the same, but C++
will have better abstraction, since you will not have to manage the
tables manually.>

Manually, why? Regarding performance, see below.

Hmm... If action tables can be handled automatically by the compiler,
and provide no call overhead, maybe I should be using them!? Could you
provide me with a hint on what they are; I have to admit never hearing
the term prior to this thread.

<I would
happily sacrifice the extra cycles to get more encapsulation and
abstraction - I value my maintenance time more than the CPU's execution

time. >


Virtual functions negatively affect performance in 3 main ways:
1) The constructor of an object containing virtual functions must
initialize the vptr table, which is the table of pointers to its member
functions.

Are you sure? In the implementations I have seen (Renesas C++ and GCC),
the vtables are created as constant data. The only thing initialized in
the constructor is a pointer to the current data type's vtable.

2) Virtual functions are called using pointer indirection, which
results in a few extra instructions per method invocation as compared
to a non-virtual method invocation.

On the Renesas H8S processor, with GCC and optimization on, the extra
indirection consists of two assembler instructions. This is not much,
to me. My default strategy would be to allow virtual functions
anywhere, and then later on check the performance. Are there two
classes in my system that suffer heavily from the extra indirection?
OK, then I rewrite those two. As someone else said: "Premature
optimization is the root to all evil."
BTW, how will the function table approach work here? Will it really
have zero overhead, compared to a direct function call?

1,2) Becomes an even larger performance problem if the base class is
virtual. Some, as EventHelix (strong C++ supporter) even tells people
not to use it at all for this reason.

That is true, here the compiler will start putting out thunks. As
others have pointed out: the feature is there, and we choose when to
use it. In each individual instance, the designer will have to weigh
the pros and cons. Is the additional elegance worth the performance
penalty?

3) Virtual functions whose resolution is only known at run-time cannot
be inlined. (For more on inlining, see the Inlining section.

Again true, but would that not also be true if you are calling
functions through an action table?

Measurements in C/C++ Users Journal (June 2004) show that a call to a
virtual function takes 8 times the time of a inlined function.

Would not that depend a bit on the size of the function body? Have they
been measuring that on simple "get/set" functions?

<I would
happily sacrifice the extra cycles to get more encapsulation and
abstraction...>

- Abstraction is not a feat of OO but your mind. It's about conceptual
categorization. Babbage used abstractions...
- The necessary encapsulation can be achieved in procedural C++, an
anonymous namespace means private, the rest is public. protected is
considered even by Bjarne Stroustrup to be a language flaw.

Yes, I quite agree that OO did not invent, or is the only answer to
encapsulation and abstraction. I have done my best to use these things
in C, assembler, SDL, etc. However, I think C++ offers a few neat
features that help, and that inheritance and polymorphism are among
those features.
Aargh - it hurt being hit by a Stoustrup quote. Do you have a reference
for it, so I can look up the context? I must say I am a bit surprised
he dismisses protected; in his book "The C++ programming language" he
describes how protected is used to differentiate between derived
classes and "the general public" without providing any indication he is
the least displeased with it. A direct quote: "protected is a fine way
of specifying operations for use in derived classes" (section
15.3.1.1.)

Ok, I have to admit, when I wrote the most radical things about
inheritance I was upset beacuse that guy called me a troll without
understanding the least bit what I was talking about. Being a
condescending ass and all...

Inheritance is NICE if performance is of less importance AND you are
coding to meet requirements that are not a moving target (a system/CPU
architecture or GUI may be examples of this). I and many others who
work close to a customer who needs new features every 6 months (which
many times contradicts the requirements handed to us 6 months before)
move away from inheritance and move towards delegation. Why? Basically
because reality force us to constantly re-evaluate our abstractions,
and many times due to times constraints, violate some of them...
Delegation is more 'elastic' in these cases I think.

I am getting this warm, fuzzy feeling of agreement here - soon we will
be holding hands and singing by the camp fire...
That last sentence made it interesting again... do you have any
examples of how delegation provides that extra flexibility?
When you prefer delegation over inheritance - is it for flexibility or
performance reasons? If the latter, would not delegation also incur a
performance hit compared to a direct function call, as we traverse a
delegation chain?

 

[Cy Edmunds]

Hi again

<I do not really see any advantage. If the object needs the members,
they must be created. This does not change when using the procedural
approach. >
Ok, a small example:

class File {

// members
string myName;
Contents* myContents;
int mySize;
unsigned char[10] myAccessRights;
};

Now, if size is the only thing I am interested in I get 3 unnessecary
object creations at File instantiation. If procedural:

int aSize = -1;

openFile( "filename.etc", nullptr, &aSize, nullptr );

Hope this makes sense?

<OT>
</OT>

BRs
/Sune

I will point out that both examples are perfectly valid C++. Your idea that
C++ is an OOP language is only true if you insist on programming it that
way. The dictum "everything is a class" is for Java programmers.

Like you, I have slowly drifted back toward a more procedural approach but
that doesn't mean C brings anything to the party. BS says he wants C++ to
be, among other things, a better C, and I think he has succeeded. I use C
for DLL interfaces and nothing else.

The STL approach of containers, iterators, and algorithms has the effect of
keeping the code and the data completely separate which is actually the
opposite of OOP. It could well be described as a lean C-like procedural
programming language with small clever objects. In short, I would have
guessed you would love it. Perhaps you are put off by the grotesque syntax
which can result from trying to splice together a large number of obscure
STL functions and classes. I certainly am! Overall though I am an
enthusiastic proponent of the STL style.

If you hate STL so much I'll bet you don't know it very well. Get yourself a
copy of Josuttis and study up. I think you will find a lot to like.

 

[mike]

HI,
Sorry, I use boost but have never seen boost::scope_guard. I googled
for it and searched the boost.org, but can't find it, except for the
boost::multi-indexewd container... could you please give me either an
introduction to it, or a link or some more keywords to plug into
google!!

Vibes

Mike

 

[__PPS__]

maybe boost::scoped_lock?

ps. I think this discussion is usless bull..hit - to me it seems that
the OO should go study programming first. Yeah!, his points sound more
like reasoning of first-year student... The fact that he'd been working
for 8 years with c++ tells nothing about his knowledge

pss I love boost

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

maybe boost::scoped_lock?
like reasoning of first-year student... The fact that he'd been working
for 8 years with c++ tells nothing about his knowledge

I readed recently this quote: "Some people has 20 years of experience. Some
other has 2 years ot experience repeated 10 times".

 

[arketype]

Yeah it is a implementation detail in some library, I am pretty sure it
is multi_index (boost 1.32). Right now it is a reformat of
Alexandrescu's original article, but it will probably be in the next
boost main dir with few, if any, modifications.

Regards,
JJJ

 

[arketype]

Sorry for being the devils advocate, but other than the OP's demeanor I
find few objectionable things in his argument. There is no homogenous
programmer, and he makes a few good points. I do work in realtime
software and frequently bypass the STL for technical reasons, despite
how insignificant they may seem to application developers. When I first
entered RT programming I thought all the developers were absolutely
nuts, they gave me advice which directly conflicted with much I had
learned before. So lets try and keep an open mind, and lets not resort
to name calling.

Excuse the lecture,
JJJ

 

[__PPS__]

ok, he was in real time programming for many years, whatever - it
doesn't mean that without knowing the language well enough he may judge
it based on his probably limited experience. Moreover he contradics
himself often - you are never forces to use things that you don't
need/don't like.

personally I think that stl alows creation of objects that are quite
"..small, lean and clever". Objectes are thmselves are light-weight.
Read some book/online tutorial about stl - you'll like stl. It just
takes time to learn it well...

- Inheritance, school book nonsense.
- Polymorphism, a consequence of school book nonsense. Waste of CPU.

bullsh..t... read on that school book again to understand better.
Read faq-lite at www.parashift.com/c++-faq-lite/ also,
as I recall correctly it states somewhere that there's no OOP
programming in c++ without polimorphism and without virtual keyword

Use an action table with procedures instead, same abstraction
and encapsulation, no performance penalty.

Insane crap - not going to discuss with you how things usally
implemented, but if you believe you can do better than it's implemented
in the current language - submit proposal to the standard's cometee for
review (but don't forget to read some school book before that).