Darin McBride wrote in a message to Tom Brown:

 DM> C++ has more runtime checking.  Objects also use more
 DM> runtime checking than non-objects, ESPECIALLY once you put a
 DM> single 'virtual' function in!  It has much checking of the
 DM> pointers to figure out if this is a base object, or a
 DM> derived object, and how many derivations it has gone through
 DM> and... well... this happens at link time sometimes, and
 DM> runtime other times.

This is absolutely wrong.  When C++ calls are made which can be early
bound, there should be no run-time checking at all.  This is an essential
part of the design of the C++ language, and the underlying reason for its
efficiency relative to other object-oriented languages such as Smalltalk. 
Even when virtual functions are used, only the functions actually declared
and defined as virtual are late bound and have any run-time penalty.  Even
when a call is made to a non-virtual function in a derived class which is
overloading a function that is virtual in the base class, that function is
itself only late bound when called from the base class, but it early bound
when called from the derived class.

 DM> I was under the opposite impression, since I know not all of
 DM> the main C libraries are compiled into my executables... :-/

The granularity of the linker is more or less an OBJ file.  There are some
exceptions, usually involving redundant code reduction when templates are
involved.

 DM> When speed becomes a problem, concentrate on that area.  If
 DM> you find a function eating way too  much time, first try
 DM> getting it into another thread.  If it is still killing your
 DM> CPU, or you cannot change threads (such as anything I write
 DM> - I haven't figured out all the proper stuff yet ),
 DM> hand-tune the routine via inline assemebly.  Otherwise,
 DM> don't worry about it... :-)  We all have 33 million cycles
 DM> every second or more, so another 100 isn't going to kill
 DM> anyone. 

You are confusing things which have nothing to do with each other.  It is
possible that an extremely efficient routine will peg the CPU doing useful
work, while a less efficient routine might force the CPU to wait because of
I/O delay, instruction scheduling, pipeline flushing, or any number of
other reasons.  On the other hand, it is also possible to peg the CPU with
a wait loop that does no useful work at all.

 DM> BTW, this is more of a C++ question, and maybe should be
 DM> taken to C_PLUSPLUS instead.

Not once you start mentioning threads.
 
-- Mike


---