Re: is C necessarily faster than C++

Bill Leonard (bill@amber.ssd.hcsc.com) wrote:
: > class A {
: > int a;
: > virtual int foo() { a++; bar(); return a++; }
: > };


: > The variable "a" is scoped, but it could be an aliased heap location.
: > Without information about bar(), the compiler must spill "a" to memory
: > before the call (and similarly around writes through many pointers and
: > arrays in C).


: How is this different from a global variable in C? You are certainly
: correct that "a" may be aliased, but I fail to see how this makes C++ any
: worse than C.


The problem is one of relative frequency. In C, programmers experiences
the "hidden" aliasing problem only when they take a pointer to a local
variable (since accesses to heap structures requires an explicit indirection
through a pointer). C++ has both a high number of function calls and
the aliasing problem of instance variables, which accessed directly
(syntactically) like local variables.


: First of all, one should not make a function virtual in C++
: unless you really need different implementations for different classes.
: But in that case, you would have needed some sort of decision structure ...


I fully agree that virtual functions should only be used when a decision
with respect to the run time type is required. However, here is where
implementation and specification conflict. The creators (specifiers) of
a library do not know all the ways it will be extended. Hence, in order to
prevent the consumer of the library from having to modify it, they will use
virtual functions at all possible extension points. A good implementation
would only use virtual function where required. Unfortunately, because of
separate compilation in C++, in general, the compiler cannot break through
the abstraction boundaries to statically bind such functions.


: > -- Specialiation (Customization/Cloning): replicate methods for
: > particular situations:


: > class A {
: > virtual int bar() { ... this->foo() .. }
: > virtual int foo() { ... code block 1 .. }
: > ...


: > class B : A {
: > virtual int foo() { ... code block 2 .. }
: > ...


: > If we replicate bar() into class B we can now inline A::foo()
: > into A::bar() and B:foo() into B:bar().


: Are you suggesting that the programmer do this, or the compiler?


The compiler. This particular example comes from an early S{\sc elf} paper,
however more recent work, including our own in the Illinois Concert project, is
more sophisticated, replicating subtrees of the call graph based on
the types of arguments other than "this", and even the types of instance
variables of arguments.


: > It follows that separate compilation of C++ programs can (fundamentally)
: > inhibit these optimizatins.


: Not if the compiler keeps a program database.


A program database is a violation of strict separate compilation. If I
get an object file (library) and header files, the compiler cannot (short of
rewriting the executable) inline functions from that library much less
replicate and specialize portions of the library.


--
John Plevyak (plevyak@uiuc.edu) 2233 Digital Computer Lab, (217) 244-7116
                          Concurrent Systems Architecture Group
                          University of Illinois at Urbana-Champaign
                          1304 West Springfield
                          Urbana, IL 61801
<A HREF="http://www-csag.cs.uiuc.edu/individual/jplevyak">My Home Page</A>
--

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