Converting GCC to C++

For a long, long time? I think the gap was something like three years between Cfront and G++.
It might have felt like a long time then, but it really wasn't. :)

My understanding is that what you say is true in modern compilers only for virtual functions
defined in virtual base classes. Non-virtual-base class virtual function lookup requires only
a single pointer dereference, from a fixed offset in the VMT, as does lookup of a virtual
function defined in a class that has virtual bases, but not itself defined in that virtual
base class or one of its ancestors.

Virtual base classes are rare. This is one reason why. (Another reason is that, well, the
designs that require virtual bases are generally either involuted or icky.)

What you say is true, but it's mitigated in a few ways:

- None of this matters if the actual class of the object is known.  It only matters if you're
accessing a derived class via a base class pointer.

- If you're accessing several virtual members, the dereference to get the virtual function
table only needs to be done once.

- Virtual methods are rare in C++ (compared to e.g. Java).  I don't believe there are any at
all in the standard library, for example.

- Using less memory per object will improve your cache hit rate when you have more than a few
objects.


Here's a C++ benchmark.  "----" indicates a new file, to prevent too much being optimised
away:

struct base {
  virtual void foo() = 0;
};

struct derived: public base {
  void foo() {
    f1();
  }
};

----

int main()
{
  for (int i=0; i<100000000; ++i) {
    base* p = f2();
    p->foo();
  }
}

----

void f1() {
}

base* f2() {
  static derived d;
  return &d;
}


And here's a C version (well, actually it's still C++ but it's using a function pointer in the
struct rather than a virtual function):

struct base {
  typedef void(*foo_t)();
  const foo_t foo;

  base(foo_t f_): foo(f_) {}
};

----

int main()  // same as C++ version
{
  for (int i=0; i<100000000; ++i) {
    base* p = f2();
    p->foo();
  }
}

----

void f1() {
}

struct derived: public base {
  derived(): base(&f1) {}
};

base* f2() {
  static derived d;
  return &d;
}


Comparing these programs (x86, gcc 4.3.1, -O3) I find that the "C" version is about 20%
faster, or around 6 nanoseconds per call, on this 1 GHz VIA C3 machine.  That fraction would
clearly drop if you actually did something inside the virtual function.

> virtual function are a lot slower than the direct C equivalent.

How would you do in C then?  Because however it is, it can be done that way in C++.

More seriously though, you are saying that C++ does something like:

this->v_btl->virtual_call(params); right?

I would agree, but how would you do this any faster in C?  Recognize that you may not cast the
object pointer to a derived class, the compiler can't (necessarily) know that the conversion
is valid, and you could cast it in C++ if the programmer happens to know more than the
compiler.

i.e. if you were to do:

derived_virtual_impl(klass, params) in C, you could do:

obj->Derived::impl(params) in C++ and call the appropriate implementation directly.

Is there some neat-o technique I'm missing?

Sorry about replying twice but I missed this one too:

> C++ has also linker problem: dynamic linking is a lot slower (number of 
> function, but also because long names, which differentiate only at the
> end)

This is annoyingly true.  However, this has pretty much been rectified.

With recent binutils (I think 2.17.50 or later?) a new hash table format is used for ELF
dynamic binaries which significantly reduces the amount of string comparisons that must be
done in order to properly load a symbol.  Of course long symbol names still take a while to
load so it is important to reduce the amount of symbols used to the minimum necessary.  If you
have recent binutils you may already be able to see the fruits of this, you can use readelf -d
to see if you have a GNU_HASH section of a binary or a .so.

g++ since 4.0 has supported visibility for symbols, including symbols defined as part of C++
class and template generation, which takes care of that problem.  The problem is that C++
libraries must specifically support it, but support for that is growing.

prelinking provides benefits on top of that.  There are patches from Michael Meeks floating
around to allow a flag called -Bsymbolic which apparently also helps, but I don't really know
what it does beyond that, and it does not look like it will make it into binutils anyways.

But there's lots of work being done to rectify these problems, so it lookslike we're *almost*
getting to the point to where we can have our cake and eat it too. :)

However, do you really fancy writing all of your algorithms as macros?  Of course impressive
hacks are possible as one-offs.

The fundamental advantage (inlined templates over macros) is that the compiler knows what's
going on.  First, it can provide type checking, which with good design can prevent many usage
errors.  Second, it can provide type-based dispatching, enabling different algorithms to be
used for different data structures.  The optimal sort for a three-element array is
fundamentally different from that for one of unknown size.  The optimal sort for a linked list
is conceptually similar to that for an array, but an entirely different code sequence.  

Using template type matching, you can present the same interface for all these cases, and
generate appropriate code for each.  Try doing that with C macros, or even Lisp macros.

You might provide macros for all the cases, under different names, but you probably wouldn't,
because you could only use them locally.  Templates may be packaged cleanly and safely enough
to be generally usable, justifying more attention to their creation and distribution.

C++ may be faster in other places.  In a deep call chain, where each caller must check and
dispatch on the return value of each call, using exceptions well instead can make the code
both faster and much more compact and readable.  A taste of the difference may be seen in
numeric codes that rely on checking for Inf and NaN at the end of a computation; imagine
checking for all those conditions after each multiply!

> Can an ANSI C compiler build gcc?

Yes.  Indeed, until a few years ago, GCC could be compiled with pre-ANSI compilers.
Thankfully, functions now have prototypes.

On the trusting trust issue, there's nothing to stop you starting with your own trusted C
compiler, compiling gcc/g++ 4.3, then using those to compile gcc/g++ 5.0.

It's easy to speculate, but since he's actually doing the work, we'll see.  If it's not really
better, it won't be merged.

'Start using exceptions' is probably quite a bit less important than 'start using typechecked
STL structures in place of rather horrible macros without type-checking'.

Given enough developers, all steering committees are ... "shallow" ;-) .
Remember EGCS?

Yes, Linus usually has strong opinions.
Sometimes I wonder a bit how he gets away with that.

Anyway, in the last years I didn't notice any portability problems with 
STL. CMake uses STL and builds with more or less all C++ compilers on all 
platforms you can imagine, including e.g. the HP-UX C++ compiler, MSVC 6, 
both which are usually somewhat problematic:
http://www.cdash.org/CDash/index.php?project=CMake

Alex

I completely agree with Linus!

I think so too. When avoiding RTTI and exceptions, and using templates 
carefully, I don't see why C++ should be slower than C.

While calling a virtual function is slower than calling a function 
directly, usually functions are virtual for a purpose. I.e. if you 
wouldn't have virtual functions, you would need some extra logic to chose 
one of several plain C functions, e.g. a switch on a type field, or a 
function pointer. When comparing calling a function pointer or a function 
inside a switch to virtual functions there shouldn't be much difference 
left.

E.g. the kernel of the embedded real-time OS eCos 
(http://ecos.sourceware.org) is written in C++, and here the developers 
surely cared about performance, memory footprint, predictability of 
execution times etc.

About the IOKit: I didn't write a driver for it, but I used the API. The 
API is C, and it uses a COM (?) object model, which makes it not too easy 
to deal with. IOW, libraw1394 from Linux was much easier to use than the 
quite overengineered (also plain C) API of OSX.

Alex

Given that Linux already has tables of function pointers all over the place, I don't think
virtual functions in C++ would be any more overhead.

I would like to eliminate integer overflow bugs by defining a safe integer class and using it
everywhere.  This is much harder to do in C.

Curiously enough, C++ has turned out to be essential to making desktop HPC workable.  The
VSIPL++ library enables users to write array expressions just as they appear in the textbooks,
and automatically distributes computations to available processors.  It uses OpenMPI (or
certain similar libraries) underneath, but almost entirely conceals their operation. Users'
only concessions to computational reality are in designating array organization -- row-major,
column-major, tiled -- and inserting the occasional copy a from an array organized one way to
another organized differently.  This is a major advance.

What is most significant is that VSIPL++ achieves all this with no assistance from
non-portable compiler extensions; it's pure Standard C++.  Essentially, C++ is powerful enough
that library writers can write their own compiler extensions, portably.

Of course VSIPL++ itself doesn't help Gcc, directly, but the power of the language can be
brought similarly to bear on compilation problems.

The C++ template system was explicitly modelled on ML's pattern-matching. 
Stroustrup says as much in D&E, and others who know have confirmed it.

(The *syntax* is insane, agreed, or at the very least really ugly.)

Not only that, there is a library you can download, just a set of ".h" files, that allows you
to write Haskell programs (with amazingly small difference in syntax from official Haskell) in
C++, and compile them with any standard C++ compiler.  

  See http://www.cc.gatech.edu/~yannis/fc++/fcpp-lambda.pdf
  http://www.cc.gatech.edu/~yannis/fc++/

This would have been impossible if C++ templates were not isomorphic to Haskell, thus to ML.

The conventional technical description of C++ template syntax is that it is "unfortunate".  It
gets substantially better in C++0x.  Obviously one can do better when starting with a clean
slate.