Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
Subject: RE: kbuild & C++
Date: Wed, 7 Sep 2005 14:04:58 +0200
Message-ID: <809C13DD6142E74ABE20C65B11A2439809C4C0@www.telos.de>
Thread-Topic: kbuild & C++
Thread-Index: AcWzkv6CJZ5YdfTXSD6u46UVfUIVagACyb6Q
From: "Budde, Marco" <budde@telos.de>
To: "Bernd Petrovitsch" <bernd@firmix.at>
Cc: <linux-kernel@vger.kernel.org>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3187
Lines: 86

Hi,

> Yes, this is a general problem with integrated c/c++ stuff like
> Win-Visual C++. 

not all Windows users do not know what they are doing :-).
Speaking for myself: I am programming under Linux and
Windows (with more than 10 years experience in C and C++)
and I do know the differences. So please do not call
people idiots only because the are writing software under
Windows.

> People think that they can mix it freely, 

They can do.

> in fact they
> are using *only* C++ (it just happens that some part of the source is
> compilable with a C compiler, but since you compile everything with
the
> C++ compiler pressing F9, no one sees the difference).

So if I compile a library with gcc and link the code to a g++
program, the complete program gets compiled with the C++ compiler?
Interesting :-).

> Why do you think are all these "#ifdef _cpluplus" stuff in the header
> files for?

To support mixed code, because otherwise e.g. a C++ compiler cannot
use a library compiled with a C compiler.

> We re on linux-kernel@ here, so we don't care *here* for user-space
> software (only for the interface - i.e. sys-calls).

When you develop a complete product consisting of the embedded
firmware, the driver, and the user space software, you always have
to decide, where to put the code. And in such a case it is really
nice, when you can use the same language in all layers.

> And for embedded usage C++ is unsusable in user-space too since it
will
> ex-bloat the whole software if people simply pull-in usual and/or
common
> C++ libraries like the STL and use them without knowing how much
object
> code they explode with it (if used without thinking).

This applies for all languages. If you do not know, what you are doing,
you can write really awful code. And I cannot agree, that C++ results to
larger code. 

> Which is again wrong. You can OO software without OO languages (though
> you loose some nice features and checking).

If you are an experienced OO programmer, you do not want to use
languages like plain C, because they result into worse code and
make life more difficult. If you do not like any kind of abstraction,
why are you using C instead of pure assembler?

> Is is impossible anyways since the in-kernel interfaces are probably
> quite different (though I don't know anything about ).

A lot of code (backend code) does not need any access to
libraries/interfaces.

> First, how much of it is really the source of a kernel driver (in the
> sense of a Unix/Linux kernel driver)?

At the moment you really need all the code to control all variants of
the hardware. Yes, it is not a good design. We know it, our customer
knows it, but at the moment we have to live with the situation.

> And second, no one expects that you convert your driver source. Just
> write it from scratch 

Can you estimate what such a redesign would cost our customers?
You would need several years to redesign the concept.

cu, Marco

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/