Re: How Type-Safe is C++?
Mathias Gaunard wrote:
On 18 juin, 04:32, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
a. aliasing
b. const values are not constant
c. dynamic arrays are represented (as far as the compiler knowledge of
it goes) as pointers
Analyze the function body and see what you can deduce from it.
I don't personally have the theory that proves it, but I suspect that
this is a simply impossible task. Years ago when I worked on a Java
compiler, I tried pretty hard to figure out a way, using data flow
analysis, to eliminate array bounds checking. I could eliminate a check
here and there, but not enough to make a difference. I don't think
anyone has solved this problem, and it's analogous to the aliasing,
non-constant consts, and pointer problems.
A type inference mechanism in language like ML would like to do
something like this anyway.
It's possible to design these types of issues out of the language, for
example by eliminating pointers, but I know of no way to figure it out
given C++'s semantics.
e. compiler has knowledge of only one compilation unit at a time
Separate compilation is a fairly good thing.
However it should be possible to work at link-time too. But while
doing things at static link-time is a good idea, doing so at dynamic
link-time isn't. So we really need to differentiate the two.
Of course, that could be solved by having some global C++ virtual
machine with runtime template instanciation (which could also be
useful for sharing these across different applications).
g. compiler has no knowledge of complete polymorphic class hierarchy
(precluding many optimizations that could be done with such knowledge)
That is available at link-time, and indeed allows great oppurtinities,
not only optimizations.
You can make virtual template functions if you
know the whole hierarchy.
That fails as soon as DLLs are supported, or if for some reason you do
not wish or are unable to provide all the source code to the compilation
system.
A simple language change, like providing a 'final' qualifier for the
most derived class declaration, means that there are by definition no
further derived classes. This is a vastly (and I mean vastly) simpler
means to achieve those optimizations than attempting to transfer the
compiler into the linker. It has the further benefit of documenting for
the user that the class cannot be derived from.
Think of it like const. The compiler perhaps could analyze the whole
program to determine if a function possibly modifies its arguments, but
we find it useful to have a const attribute anyway in order to both
*document* and *enforce* the interface.
---
Walter Bright
Digital Mars
http://www.digitalmars.com
C, C++, D programming language compilers
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]