Re: Dynamically choosing what to "new"
On Jun 12, 1:40 pm, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:1181638736.619838.221380@i13g2000prf.googlegroups.com...
On Jun 12, 1:29 am, "JohnQ" <johnqREMOVETHISprogram...@yahoo.com>
wrote:
"Gianni Mariani" <gi3nos...@mariani.ws> wrote in message
news:466d1096$0$22407$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
JohnQ wrote:
"Gianni Mariani" <gi3nos...@mariani.ws> wrote in message
news:466ca01f$0$22432$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
JohnQ wrote:
...
Note that "copy-on-write" _is_ an optimization.
Yah - but it's an optimization made by the compiler not be me.
No, no, it's coded into the string class (user-level stuff).
I lumped the STL as part of the "compiler" in the statement above.
I know, that's why I posted: it's incorrect.
"In what sense? As far as the standard is concerned, the
standard library is part of the language. You get it with the
compiler, and use it as if it were part of the compiler. The
compiler is aware of certain parts of it, at least (e.g.
type_info, or operator new()). Most implementations do allow
replacing a significant part, at least if it is done as a block,
but that's an extension, and you normally think of the standard
library (plus a number of system libraries, such as the Posix
interface) as being part of the "implementation", in other
words, the compiler. You don't worry about how
std::basic_string is implemented, you just use it."
Correction: that is how YOU perceive it.
Correction: it's how the language is defined. Every language
I've ever used is defined in this way.
I don't even think of a vendor's combination as an entity: I
may use JohnQ Templates rather than the STL that comes with
it.
No you may not. If it works, it's an extension on the part of
the compiler. And it doesn't always work.
When someone say's "compiler", I indeed think the executable
that does the compiling of source code into machine code or
assembly. In the other case, I'd use "development
environment", VC++ or similar terminology.
That's a more or less frequent distinction. We speak of
compilers, linkers, library components, etc. to refer to parts
of the implementation. But the implementation is a monolith;
you can't mix and match different parts. And the distinctions
are blurred; most systems today will generate code at link time,
given certain options, and there is a definition interaction
between the library and the language in certain cases, such as
std::type_info. In the past, C compilers regularly "knew" the
semantics of certain standard functions (and generated them
inline), and it's to be expected that in the future, C++
compilers will know the details things like std::vector.
The standard is very clear about this. There's really no room
for discussion.
--
James Kanze (GABI Software) mailto:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34