fjh@cs.mu.OZ.AU wrote:: That's not correct. Although you can write code which does this, such: code is prohibited by the draft ANSI/ISO C++ standard (see section 3.8).: The sample program you listed has undefined behaviour.: The C++ committee was careful to make sure this optimization was allowed.

You are right, the committee "kluged" the language definition.

However, as a language implementor, one has to ask if the speed advantage
is worth the obscure bugs. Many programmers (especially the vast
majority that have moved to C++ from C) have a view of C++ "objects"
as structure with a virtual function table pointer. Their interpretation
of the meaning of the programm is at that level, and they are just as likely
to take advange of that as they were with C. For example, nomatter
how glorified, inheritance in C++ is largely the result of memory map
compatibility of strutures which share the same initial fields,
(an artifact of C implementations which programmers have been taking
advantage of for years).

Moreover, compilers for languages which serve as systems programming
tools have different requirements than those that implement high
level abstractions. They must use a relatively literal mode of
translation so that the programmer can reason precisely about space,
time, and interactions with other parts of the system.

For example, in an embedded system a light weight control process
might overwrite the state machine objects for slave processes.
While such overwrite problems exist in C for separate processors
(hence "volatile"), the impact in C++ is more insidiuous since
undefined behavior can without special hardware.

C++ is also the target of extensions for persistence, distribution,
parallelism, garbage collection, new languages, etc. These extensions
often involve source to source translation + a runtime which moves
memory, swizzles pointers and generally breaks the abstract "object"
model.