Re: C++

[Andreas Kostyrka <andreas ag or at>]

On Sun, 19 Apr 1998, Scott MacDonald wrote:

> 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
Correct. But they have an enorm overhead when compiling. Instanting one
template may cascade in instanting a dozens templates.
And they have a code size overhead. And they still don't let me design my
application I want, but I've to take into account that C++ lacks critical
features while providing many unneeded features.
(For arguments about this, consult the TOM homepage and follow the link
 ``Why a new OO language'', which describes why C++ is not a valid choice
 for system building. http://www.gerbil.org/tom/ )
> 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
But many times you want a Runtime checking. What about a container that
may store anything.
- Ok, lets store a pointer to an abstract object, and derive all
  things we want to store from it.
- But the things that I want to store come from different libraries?
  And actually I'm just storing them to print them, and that all objects
  know how to do :)
- Oops, in C++ I'm back to wrapping all needed objects for my container.
Not what I'm considering a nice way to do things.
Basically speaking, C++ is better??? C, but surely not really OO.
And about being better, there is always the problem, that it has way
to many features. Any many features mean, that you have to be really
proficient to know C++ to use it to it's tilt, and that is not true for
95% of all persons thinking themselves C++ programmers.
(I'm just thinking how I've proposed some time ago an interface with
 Objects handling callbacks, and how all the ``official'' C++ gurus in the
 company couldn't understand the idea of using objects and virtual
 functions as callback function replacers, ...)

> type checking.  Templates also allow type checking for generic
> containers thus allowing you to write cleaner, safer code.
And sometimes they are not enough. C++ looses in the library writing
departement.
> 
> 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.
Not really. In C you at least know that you've to learn how things are
done in a library. In C++ you assume, and you loose. (Again, C++ has a
suspect object model: copy by value, multiple copies of one object in the
inheritance graph, etc. Funny thing is, that C++ is the only OO language
that does it this way. ADA does it do, but it has only ADT's not OO
features, ... Basically C++ mixes ADT's and OO code. And by trying this it
doesn't get 100% on both counts. Consider (astr+"ABC").c_str() for the ADT
case (still not solved the problem), and consider the lack of
late-time-bindings for the OO case.)

> 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
Exceptions are not bloat :) Again, C++ is a bit lacking in my eyes:
In a OO design, the error handling doesn't have to be always
exceptionwise, because that may cross module boundaries.
Additionally, declaring expections in the method signature is not that
cool (http://www.gerbil.org/tom/highlights/exception.shtml).
> kind of feature is needed the language implementation is much cleaner
> than any additional code you would have to write yourself.  Most
RTTI is a joke in C++. RTTI in C++ basically gives you a possibility to
downcast a inheritance tree with runtime checks. There is MUCH more to a
RTTI in a OO language, than this.
> features won't increase the size of you code unless you use them, and a
> modest cost for a new feature is not bloat.
Again, the bloat with C++ is in the features, and it's bloat because they
are the wrong kind of features for an OO language.

[snip]

> 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
procedural programming: Ok.
modular programming: 50%. Namespaces are ok, but there is still no module
                          concept like in MODULA-2 (and children), and
                          Headers still may contain way to much thinks.
                     Are you considering it clever to include the privates
                     of an object in the public interface of a library?
                     Additionally, no GC makes writing general containers
                     more difficult (solvable but more difficult), and you
                     have to remember who owns what.
> programming, data abstraction, object oriented, and generic programming
ADT's: Fairly well, but after reading Strustroups newest book,
       the question about casting Strings to char* and
       temporaries still lingers in my head. And still my private fields
       are open to depend upon (in compilation) by the client. One
       change in my privates, and all compiled clients may break.
object oriented: Not really. C with GTK is not less object oriented than
                 C++. It lacks many features that languages of the
                 Smalltalk heritage have, and has many features (that
                 mostly have to do with ADT) that make it awkward.
generic programming: Nice work, but the problem is, that because C++ lacks
                     in the OO department, people are taking to generic
                     programming. But gives more fragile systems in the
                     end.
> (taken from ch 2 of the C++ Programming Language).  Take your choice.
> C, on the other hand only supports procedural and modular well.  The
C doesn't support modular well, and neither outshines in the procedural
area. But it is the common API of Unix: Practically all languages have
interfaces to C, while not so many have interfaces to C++.
> 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.
But this features are not really wanted in a general toolkit that binds
with many different languages.
> 
> 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.
And it's not OO, because doing it OO wise would be near to impossible in
C++.
> 
> 
> 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
Read the portability document on www.mozilla.org. End of discussion.
> 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).
C is not safe. Ok and well established. C++ isn't either too. It has all
the dangerous features of C.
> 
> 
> 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
Use the right language. I'm quite fast learning GTK and TOM at the same
time, while at the same time extending the tomgtk wrapping to do all I
need correctly (It's not that easy as I've to take GC into account.)

Try to emulate this in C++ any you are bound to fail (I'm extending tomgtk
proxy objects in my app :) ).

> 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
gtk+ is object oriented. And it is still foreign language friendly.
Just compare the number of language bindings for gtk and Qt. C++ handling
makes language bindings only more complicated.
> 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've read Stroustrops newest book (to update myself), and have found that
C++ is still lacking tremendously in the OO part, while it's generic
interfaces are on the overtake lane. Additionally, I've found that
performance is overstressed in the book, while safety comes last.
For example, it's really funny, that the STL vectors come without range
checking. It's just not acceptable in a language that claims to raise the
abstractation level, and it's basically unneeded. If I need unchecked
vectors, I'm having them basically build into the language, object x[...].

> I have really run off more than I should have, so now I'll log off,
Me too :)

Andreas