Re: C++ virtual function calls (John B. Plevyak)
Thu, 16 Nov 1995 21:05:48 GMT

          From comp.compilers

Related articles
[5 earlier articles]
Re: C++ virtual function calls (1995-10-30)
Re: C++ virtual function calls (John B. Plevyak) (1995-11-09)
Re: C++ virtual function calls (1995-11-05)
Re: C++ virtual function calls (1995-11-05)
Re: C++ virtual function calls (Per Bothner) (1995-11-06)
C++ virtual function calls (1995-11-12)
Re: C++ virtual function calls (1995-11-16)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (John B. Plevyak)
Keywords: C++, optimize
Organization: University of Illinois at Urbana
References: 95-11-039 95-11-105
Date: Thu, 16 Nov 1995 21:05:48 GMT 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"

Just one more reason why C++ makes a bad "generic assembly language".


    John Plevyak ( (217) 244-7116 PGP KeyID: 0x051130BD
                          Concurrent Systems Architecture Group
                    University of Illinois at Urbana-Champaign
      2233 Digital Computer Lab, 1304 West Springfield, Urbana, IL 61801
<A HREF="">My Home Page</A>

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.