[sdiy] was how_you_got_started...

[Phillip Harbison]

Jay Schwichtenberg wrote:
> I didn't do the research. The people I worked for did this
> about 4 years ago and all they said is it was the run time
> library. What that includes I do not know.

At the lowest level, the main overhead of C++ is the virtual
function table and the code to navigate that table, all of
which is constructed by the compiler and linker. Otherwise,
C++ code should perform about the same as C code.

At the next level, if you want to use the "new" operator you
will need a way of managing heap memory. There are some very
compact implementations of this, so I would not allow it to
deter me from using "new". The bigger issue is how you get
that heap memory. If there's no OS, then all memory is yours
for the taking minus whatever you allocate for stack.

At the next, next level there's all the standard library
code which is rather large, but there's no reason you have
to use it. I'm not a big fan of the way templates are used
in the standard library anyway. It seems counter to the
way templates are used in Stroustrup, which is to define
a generic base class and then use templates to perform type
coercion, somewhat like the way generics are implemented
in Java.

You could always take the standard library code from GCC
or any other open source version and strip out everything
you don't need. I did that in the old days with C and the
C standard library. We ripped out all the floating point
support which we did not need, which was a huge portion
of functions like printf and scanf.

I'm not necessarily advocating for C++. You have to decide
if it's the right tool for the job. If the only tool you
have is a hammer, every problem looks like a nail. I use
{Java,C++,C,assembler,microcode*} when it's the appropriate
tool for the job.

(*microcode as in programming bit slice processors, which
was similar to programming DSPs and VLIW processors)

-- 
Phil Harbison