Tom Brown wrote in a message to All:

 TB> I have been using C++ for some time now.  As a long-time C
 TB> programmer, I don't use the object oriented features as much
 TB> as I might.  It seems as though a simple program with no
 TB> templates, OpenClass objects or containers comes out much
 TB> larger than it ought to.

 TB> What I like most about the language is the way it lends
 TB> itself to grouping related functions.  My code looks like C
 TB> code except I do use cout and cerr all of the time.  I've
 TB> often wondered why a simple program with a main() and one
 TB> object with four methods (functions to me) needs to be 40K
 TB> when the same thing in C comes in at 14K.  I don't mean a
 TB> similar thing in C.  If you take the C++ object and simply
 TB> break it down into the four functions and compile the whole
 TB> works as C code, it comes in a bunch smaller.  The size
 TB> increase with C++ starts with larger .OBJs and more run-time
 TB> code is linked in, as well. 

The iostream library alone will account for significant code bloat.  You
should understand that iostream is not simply a thin layer above the usual
C-language stdio.h functions.  Rather, iostream is an intelligent system
which handles objects using intimate knownledge of their types, and it must
be able to get this information from whatever mechanism is supported by the
compiler, from compile-time built-ins to RTTI.  Just because you only send
built-in int and char[] to cout does not make the library any smaller.

 TB> I know that with C, I need to keep each function in it's own
 TB> source file so that the linker can link in only the
 TB> functions that it needs.  I'm talking about object libraries
 TB> specifically.  C++ seems to get out of hand if you put each
 TB> method into it's own source file.  I've got some pretty big
 TB> objects (all in one source file -> a .CPP and a .HPP), so
 TB> I'm guessing that if I instantiate one of these bad boys I
 TB> get the whole thing regardless of what methods are called in
 TB> my application. 

This is a trade off with C++.  As you put more and more stuff into a single
source module, the compiler gets more efficient but the linker gets less
efficient.  Especially if you use templates, a great deal of the efficiency
of the system depends on the linker rather than the compiler.

 TB> Curiously, I find the performance of C++ to be very near C
 TB> when I don't use C++ specific features, even though the
 TB> .EXEs are larger.  I don't care about hard disk space, but I
 TB> would like to code as efficiently as I can.  Perhaps someone
 TB> could shed some light on this, point me to a resource on
 TB> this subject or, heaven forbid, tell me what I'm doing
 TB> wrong.  So far, my main C++ reference has been Stroustrup's
 TB> second edition.  My compiler is IBM VA C++.

You are probably not doing anything wrong.  C was intended to work as a
kind of high-level assembler, but C++ was not.  On the other hand, careful
attention was invested in performance issues in C++, since that has
traditionally been a main criticism of object-oriented languages such as
Smalltalk.  Templates, for example, are really a performance issue rather
than an important conceptual issue.  In some cases, the C++ template
implementations of algorithms are comparable to the fastest known
implementations in any lanugage, including assembler, on the same platform.
 Stepanov has written some interesting articles on the HP implementation of
the C++ Standard Template Library from this perspective.

 TB> BTW, I realize that a more powerful language will tend to
 TB> generate more .EXE per line of code.  With C++ having the
 TB> capability to be so similar to C though, I can't help but
 TB> wonder.  Thanks in advance. 

It's just bigger, not slower.
 
-- Mike


---