Re: is C necessarily faster than C++

ruiter@ruls41.fsw.leidenuniv.nl (Jan-Peter de Ruiter) writes:


      However, in practice, because every complex object has both a constructor
      and a destructor, there is an additional function overhead cost.


      It is said that these can be inlined, but not all compilers do so,
      and it's not always possible either. More importantly, constructing
      and destructing local complex objects takes a lot of malloc-ing and
      free-ing. Experienced C programmers having to write efficient code
      usually avoid many calls to malloc by fooling around with pointers
      and keeping track of allocation themselves.


?! I find that experienced c programmers worry more about correctness
and simplicity (i.e. how long is it going to take to code this)
than speed.


it's the inexperienced programmer who worries a lot about speed
before it's known to be an issue.


      Take a C program that manipulates strings. Experienced C programmers
      will keep track of what string resides where, avoiding unneccesary
      copying. Now using a good string library in C++ relieves you of the
      burden of keeping track of your memory, but it adds the overhead of
      constructing and destructing them.


You can write constructor/destructor based c libraries
you can write pointer-based c++ libraries.


I don't agree with "c is so" and "c++ is elseways":


(Very) theoretically, every c program is also a c++ program
that gets more warnings when run through the compiler. So
c libraries can be used as c++ libraries.


I think the difference between c and c++ usage is mostly cultural.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.