Re: C++

[Scott MacDonald <smacdonald seimac com>]

I'm really weary of posting this at all, after all these discussions
tend to follow personal preferences and many degrade into name calling
or religious wars.  However many of the posts I have seen, even the
status report on the Gnome home page, shows a misunderstanding of what
C++ is, and of where the language is today.  I believe that this group
has the potential to generate a product that will influence a lot of
coding and design issues related to Linux applications.  I hope the
decisions made are informed.  The sheer volume of this list means that I
may have missed some important input to this topic, and I do apologize
for adding to it, but here I go anyway...

The Bloat.

There has been some discussion of the overhead, or the bloat of C++.
For example the status report states "We have to thank whoever came up
with C++ Templates for this bloat", with reference to the CORBA stubs.
Templates should have ZERO overhead in space or processing in the final
object file.  If you need proof just try it your self.  Write two small
programs, one that makes use of a structure that explicitly defines the
type, and another that uses a template.  Compile these and see (on HP-UX
with aCC the files were identical, using g++ there was 1 byte
difference).   In many instances templates reduce the number of
functions that have to be supported, or reduce the need for run time
type checking.  Templates also allow type checking for generic
containers thus allowing you to write cleaner, safer code.

As for bloat of other features, such as the standard library, the
results are similar, C++ is very efficient.  For example compiling a
simple program with a C compiler and a C++ compiler, dynamically linked
resulted in 0 byte overhead for HP aCC/ansic, and 108 bytes with
gcc/g++.  For statically linked the files were the same size with
gcc/g++.  As you bring in more features you will have to pay for them,
but this is not much different than using additional libraries for C,
and far superior than hand coding these features yourself.

Features such as exceptions and RTTI have been mentioned as extra
bloat.  Exceptions allow an error handling model that can be more
flexible and safer than anything C has to offer.  As for RTTI, when this
kind of feature is needed the language implementation is much cleaner
than any additional code you would have to write yourself.  Most
features won't increase the size of you code unless you use them, and a
modest cost for a new feature is not bloat.

Some of the bloat seems to come from early implementations of features
in compilers.  Most of the bloat is the design of the application or
library itself.  If you ever see an inheritance tree ten deep, beware.
If you see every method declared virtual, there is a cost.  Other
sources of bloat I have seen are from poorly designed operator
overloading, poor handling of temporary objects, and of misuse of an
otherwise solid library.  For the CORBA stub example above you should
probably look at improving the generated stubs rather than blaming the
language for the bloat.  A quote from 'The C++ Programming Language'
covers this, "Don't believe in magic; understand what your libraries do,
how they do it, and at what cost they do it".   This should apply to all
languages, not just C++.


C++ == Object Oriented

C++ is a general purpose language.  There seems to be an idea that if
you want to do object oriented programming use C++, otherwise use C.
This just isn't the case.  C++ supports procedural programming, modular
programming, data abstraction, object oriented, and generic programming
(taken from ch 2 of the C++ Programming Language).  Take your choice.
C, on the other hand only supports procedural and modular well.  The
others either can't be implemented or require the programmer to code
around the problem with hacks and enforce these though policy, rather
than though language features.  On top of this C++ adds stronger typing,
exceptions, name spaces and many more features.

Even if you are not a fan of object oriented programming give C++ a
try.  For example the Standard Template Library, as part of C++, is NOT
object oriented, it follows generic programming.  Understanding the
theory behind the STL is well worthwhile, especially for someone doing
designs.  To implement the STL in C would be next to impossible.


Risk of new features.

There have been many people burned, myself included, by making use of
some of the newer features of C++.  Templates were a real nuisance to
implement.  C++ has matured however, and going through the standards
process has made the language stronger and the support for its features
more uniform.  With g++ 2.8 and/or egcs we have access to decent
implementations of most of these new features, including templates and
the STL.  You may still want to tread lightly with some obscure
features, but for the most part things have finally settled down.


Safety

C++, and its standard libraries, allow for much cleaner handling of
dynamic types.  Each user defined type can make use of dynamic memory
and hide the implementation from the user.  Through such features as
destructors in user defined types the language will enforce rules set by
the designer, instead of relying on the user to call cleanup functions.
For example a string in C++ is NOT char*, it is a defined type.  The C++
string is dynamic, will not overflow, and is much safer than its C
counterpart.  When the string goes out of scope it will clean up its
memory, the user need not do anything.  C++ also allows for elegant
solutions to such things as smart pointers (reference counting pointer
wrappers).


Raising the programming level

There was mention that the right solution for doing faster GUI
development is to 'raise the programming level'.  It was noted that
Tcl/Tk, or Perl binding would be appropriate.  I feel that bindings to
scripting languages are important for "glue" applications, very small
applications, and for proto-typing.  For larger scale programming we
still need to "raise the programming level", however to me this means
simplifying the API, or providing abstractions.  One method of doing
this that maps nicely to GUI development is through Object Frameworks.
Objects allow state information to be held so that the developers of the
framework can worry about many of the specifics and allow the
application developer to concentrate on "higher level" design issues.
Frameworks often present an overhead that may not be appropriate for all
applications, so that a "nuts and bolts" API must still be available
(although this too could be object oriented).  The current trend of
concurrently developing gtk+ (nuts and bolts), gtk-- (slightly higher
level with objects), wxGTK (full framework), and scripting bindings may
cover all of the bases.  Visual design (GUBI) may even fill in more.


The language in general.

In general C++ is a strong language with many new features.  Before you
dismiss it you might want to check it out.

I have really run off more than I should have, so now I'll log off,
bye
Scott