C++ and C

[Dave Ciemiewicz]

In article <205*doelz at urz.unibas.ch>, doelz at urz.unibas.ch (Reinhard
Doelz) writes:
> Hi , 
> we are about rewriting our graphics application in order to tune code. 
> We have some own object-oriented modules which would fit 
> pretty nicely in C++ structures. However, as tuning is the 
> ultimate target, does anyone know about 
> 
> *   C++ performance in comparison to 'plain' C modular structures

It really does depend on your application and how you implement your C++
classes and how you previously implemented the same data abstractions in
'plain' C.  For instance, the use of C++ derived classes and virtual member
functions can produce faster code than might be equivalently implemented
using a data type tag and switch statement in C.  Judicious use of C++ inline
functions can also speedup some code.

Unfortunately, no one can give you a pat answer one way or another.  There
have been some claims made on comp.lang.c++ though I haven't followed those
discussions in awhile.

> 
> *   possibility to complile/link/debug/pixie C++/C mixed code 
> 
> *   C++ and power vision calls 

C++ was designed to be fairly compatible with existing C++ code.  C++ code
can directly call the C-GL routines for instance, including the new
POWERVision calls.

The IRIX dbx has been extended to provide help in debugging C++ code.
For instance, it does name-demangling of member variables.  It doesn't do
name demangling of function names though for SGI's C++ 1.0 (AT&T v1.2.1).

We have used pixie extensively in-house in conjunction with in-house developed
C++ applications like the IRIS WorkSpace(TM) and wsh, the window shell.

> 
> *   Optimizer issues: problems with O3?

The AT&T C++ Translator from SGI just produces C code.  There should not be
any problems with using -O3 optimization.

> 
> *   System resources: more than 'usual' - ? (We got only 16 megs on a 120).

C++ tends to be very data intensive.  Experience with C++ shows that sometimes
people over develop classes and throw unnecessary information into the classes.
After a couple of levels of derivation, an instance of a class can be larger
than you would expect.  This requires the programmer to think about their
data abstractions a little more than they might of in the past.

Another area to be aware of is text space locality.  C++ derived classes are
typically implemented in there own files.  After a couple layers of
derivation, a call to a member function of a derived might be implemented to
make references to base class functions.  This is usually true of class
constructors and destructors.  This can sometimes result in less than optimal
VM paging performance.  Of course, this is true of any application which calls
functions in many different modules.

Some performance gains can be made by using pixie(1) and cord(1) to rearrange
the functions in text space so that functions which call each other a lot
are next to (or close to) each other.  This can reduce the VM resident set size
requirements of any application, not just applications written in C++.

> 
> I'd appreciate any hints. 
> Regards, 
> Reinhard 

I'm personally involved in a development project here at SGI using C++.
I also have friends at other companies who are doing development in C++.
All of them agree that you don't just learn C++ overnite, even with an
extensive background in C.  There is a learning curve associated with
the transition to C++.  This includes understanding efficiency design
considerations.  However, almost all of them prefer working in C++ versus
'plain' for object-oriented development.

Good luck!

						--- Ciemo