Re: is C necessarily faster than C++

jplevyak@violet-femmes.cs.uiuc.edu (John B. Plevyak) writes:
> Bill Leonard (bill@amber.ssd.hcsc.com) 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
Bill.Leonard@mail.hcsc.com
--

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