Subject: Re: STL efficiency (Was: Re: C++ briar patch (Was: Object IDs are bad))
From: Erik Naggum <>
Date: 1997/05/22
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.misc,comp.lang.functional,comp.lang.c++
Message-ID: <>

* Stephen Norman
| I was simply making an educated guess at why some STL code appeared to be
| much slower than equivalent hand-coded C when compiled with *one
| particular C++ compiler*, which is known to do a poor job at generating
| efficient machine code from templates.

and I was just noting that such explanations and rationalizations are
perfectly OK in the C++ world, where people will instantly look for a
better compiler or rationalize away the whole problem by "waiting for the
next version of compiler" or somesuch.  however, when an optimizable
construct is not optimized to its fullest, the common sentiment is not that
the Lisp compiler a bad choice, it's that _Lisp_ is slow.  I was commenting
on the asymmetrical attitude problem with respect to prejudice against slow
compilers and languages, that's all.

thanks for demonstrating that it's perfectly OK to blame the compiler in
the C++ world.  (if other compilers are so much better, just perform your
own comparison and post the results.  how hard can it be?)

if we work harder, will obsolescence be farther ahead or closer?