[OT] memory management -- was Re: itoa'd you so?

Bryan Sant bryan.sant at gmail.com
Wed Sep 19 23:59:43 MDT 2007

On 9/19/07, Dave Smith <dave at thesmithfam.org> wrote:
> If you do those two things, you'll be in good shape to code lots of
> awesome C++.

Thanks for the tips.

> 2. Macro-based debugging. Using the macro system, you can remove and
> insert entire chunks of code just by flipping a flag in your makefile.
> In other languages (like Java and Python), you'd have to do some serious
> magic to actually *remove* debug code from your software at release
> time, rather than just wrap them in false conditionals, to get the same
> kind of performance as C++.

A blessing and a curse.  Macro-based debugging has merit, but nasty
black magic macros used for non-debugging purposes can be a bear to
debug.  I'd also argue that the single jump instruction that is
produced with an "if (debug) {" test one would use in a language that
doesn't support macros doesn't even register on the performance
overhead meter.  This is a total non-issue as far as performance is
concerned.  However, removing the code all together does reduce the
size of your binary image which is kind of nice.

> 3. A linker! Why don't other languages have linkers these days? It's
> such a pain to kludge together jar files that you hope have all the
> classes you need to ship in one bundle. I know the Mono team is working
> feverishly to finally write a linker after how many years? Using a C++
> linker, I can create a single binary that will run on just about every
> Linux distro (even spanning kernel versions).

Boo.  Down with static linkers ;-).  Everything in java/mono is loaded
dynamically.  A java or mono linker doesn't make any sense.  If you
want to get the same effect, you'd just bundle everything up in a
single jar/assembly.

> 5. Speed. For most user-interactive desktop applications, you still
> can't JIT fast enough to match C++'s raw speed.

Not that this isn't a legitimate bragging right of C++, but modern
desktop computers are so bloody fast, that this is less of an issue.
And just to be contrary, I'd point out that post-JIT code can in fact
match the speed of C++.  The problem is that you have to incur some
latency while the JIT takes place.

> Anyway, I'll get off the C++ pedestal. Sometimes I feel like I'm still
> rooting for the losing team, but for certain applications C++ is just
> great, even if your last name isn't Stroustrup.

I don't know if I would say that C++ is a losing team.  Many may
prefer something else, but the facts are this:

Tons of jobs -- 8,860 on dice.com.

TIOBE programming language popularity list has C++ in spot #5.  That's
above heavy hitters like perl, python, C#, ruby, and javascript.


More information about the PLUG mailing list