Re: is C necessarily faster than C++ (Bill Leonard)
Fri, 30 Jun 1995 20:41:03 GMT

          From comp.compilers

Related articles
[21 earlier articles]
Re: is C necessarily faster than C++ (stanley (s.t.h.) chow) (1995-05-09)
Re: is C necessarily faster than C++ (1995-05-04)
Re: is C necessarily faster than C++ (1995-05-16)
Re: is C necessarily faster than C++ (1995-06-23)
Re: is C necessarily faster than C++ (1995-06-23)
Re: is C necessarily faster than C++ (1995-06-30)
Re: is C necessarily faster than C++ (1995-06-30)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Bill Leonard)
Keywords: C, C++, performance
Organization: Harris Computer Systems, Ft. Lauderdale FL
References: 95-04-202 95-06-041
Date: Fri, 30 Jun 1995 20:41:03 GMT (John B. Plevyak) writes:
> Bill Leonard ( wrote:
> : 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.

Okay, I understand now. Yes, I would agree that C++ does tend to introduce
more pointer indirections than C.

> 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.

I don't think that this is a practical design method. I doubt that anyone,
no matter how skilled, can design a library that can be extended in a way
totally unknown to them. One can plan for certain kinds of extensions, and
those are likely to be the only ones that work. Anything beyond that is a
pipe dream (IMHO).

> : > 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.

So who says C++ *requires* "strict separate compilation"? Certainly not
the standard.

> 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.

True. But what's your point? I don't see how *any* language could do any
better if you require of it the ability to ship a library strictly as
object code.

You pays your money and you takes your choice, I guess.

Bill Leonard
Harris Computer Systems Corporation
2101 W. Cypress Creek Road
Fort Lauderdale, FL 33309

Post a followup to this message

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