From ... From: Erik Naggum Subject: Re: STL efficiency (Was: Re: C++ briar patch (Was: Object IDs are bad)) Date: 1997/05/27 Message-ID: <3073702480536970@naggum.no>#1/1 X-Deja-AN: 244163865 References: <3072702392790368@naggum.no> <5lu7ar$2uf$1@goanna.cs.rmit.edu.au> <33860CF1.9EA0441A@ucla.edu> <5mbjag$2gs$1@goanna.cs.rmit.edu.au> <3389DF6E.55FE753F@ucla.edu> mail-copies-to: never Organization: Naggum Software; +47 2295 0313; http://www.naggum.no Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.lang.misc,comp.lang.functional,comp.lang.c++ * Max Moroz -> Richard A. O'Keefe | Well, why do you work from a Draft Standard? You can refer to it in | cases of ambiguity about what is considered portable, and what is not. | In you normal work, however, you should use the documentation provided by | the vendor who supplied your library/compiler/etc (unless the vendor | guarantees full compliance with the standard, which no current compiler | does). I can't speak for Richard, but I prefer to write my software in a language, not a particular product. I strongly prefer knowing how things should work, what constructs should mean, etc, and then augment this by a list of implementation restrictions, bugs, and other deviations. plus a full specification of the (inevitable) implementation-defined features. if this is impossible for some given language and one is expected to keep up with an increasingly erratic set of random features, I consider it a waste of my time to learn to use just a (buggy) product, except in some very special cases (like Emacs and experimental languages). #\Erik -- if we work harder, will obsolescence be farther ahead or closer?