Subject: Re: STL efficiency (Was: Re: C++ briar patch (Was: Object IDs are bad)) From: Erik Naggum <erik@naggum.no> Date: 1997/05/22 Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.misc,comp.lang.functional,comp.lang.c++ Message-ID: <3073296251831122@naggum.no> * 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?) #\Erik -- if we work harder, will obsolescence be farther ahead or closer?