Re: Compiling C++ modules

[ebiederm@xmission.com (Eric W. Biederman)]

Martin Mares <mj@ucw.cz> writes:

>> FWIW, userspace is moving away from C as unproductive and unsafe. KDE is 
>> of course C++, mozilla, openoffice are C++, and gnome is moving towards 
>> (of all things) C#.
>
> Maybe continuing to write application programs in C instead of using
> higher-level languages is silly and backward, but _stopping_ at the
> level of C++ or C# is equally silly.
>
> However, in the kernel space the main problems the people are spending
> their time with are rarely related to the language.

To some extent that is true.  There is a huge amount of work involved
with understanding the hardware.

The things we need to check in the kernel don't seem to coincide
to facility provided by any current programming language.  I can't get
the compiler to check that I don't overflow a 4K stack,  that I always
use the same permissions checks to guard the same class of objects,
that my aggressive refactoring didn't miss a subtle dependency by the
users of that code. 

Currently every language I know of are variations on a theme, that
helps to write applications and abstractions, but provides little
help in verifying those abstractions.   In essence what is
needed are compile to assertion checking.

Languages like C++ do seem to make it easier to get to a higher
level of abstraction, and share fundamental abstractions like
your object system with a large body of programs.  However once
you are at that level of abstraction in a language current languages
don't seem to provide much real additional help.

So I do agree that the improvement by a language switch is limited
by Amdahl's law, and since most coding time is spent thinking and
testing a language needs to show major gains in at least one
of those areas to really show improvement.

I think it is possible to show major gains in testing but I have
yet to see a language that address that issue.  C++ with it's slower
compiler, and greater complexity clearly will neither increase 
the frequency of tests nor the number of people qualified to review
the code.

Eric