mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bernd Petrovitsch <bernd@firmix.at>
To: "Budde, Marco" <budde@telos.de>
Cc: Esben Nielsen <simlo@phys.au.dk>,
	Jesper Juhl <jesper.juhl@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: RE: kbuild & C++
Date: Wed, 07 Sep 2005 12:00:07 +0200	[thread overview]
Message-ID: <1126087207.24425.55.camel@tara.firmix.at> (raw)
In-Reply-To: <809C13DD6142E74ABE20C65B11A2439809C4BE@www.telos.de>

BTW you kill threading.

On Wed, 2005-09-07 at 11:13 +0200, Budde, Marco wrote:
[...]
> >> That would be because the kernel is written in *C* (and some asm),
> *not* C++.
> 
> I cannot see the connection. At the end everything gets converted
> to assembler/opcode. In the user space I can mix C and C++ code

Yup. And exported symbols for the linker.

> without any problems, why should this not be possible in the

Yes, this is a general problem with integrated c/c++ stuff like
Win-Visual C++. People think that they can mix it freely, 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).
Why do you think are all these "#ifdef _cpluplus" stuff in the header
files for?

> kernel mode?

Try linking also in the user space, not only compilation.
Second read in the standards about the difference between hosted and
standalone environments and think on the differences.

> >> There /is/ no C++ support.
> 
> This will be a problem in future. Nearly nobody will start a new

No.

> larger project (driver, user space software, embedded firmware)

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

> using non OO languages today. So porting eg. Windows drivers to

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

> Linux is nearly impossible without C++ support.

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

> E.g. in my case the Windows source code has got more than 10 MB.
> Nobody will convert such an amount of code from C++ to C.
> This would take years.

First, how much of it is really the source of a kernel driver (in the
sense of a Unix/Linux kernel driver)?
And second, no one expects that you convert your driver source. Just
write it from scratch (since you know the internals of the hardware
quite well it should take only a few weeks).

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services


  parent reply	other threads:[~2005-09-07 10:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-07  9:13 Budde, Marco
2005-09-07  9:57 ` Valdis.Kletnieks
2005-09-07 10:45   ` Esben Nielsen
2005-09-07 10:00 ` Bernd Petrovitsch [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-09-15 12:35 Budde, Marco
2005-09-18 18:41 ` Sam Ravnborg
2005-09-07 12:04 Budde, Marco
2005-09-07 12:58 ` Bernd Petrovitsch
2005-09-07 13:15 ` Nick Piggin
     [not found] <4JJOt-77X-9@gated-at.bofh.it>
2005-09-07 12:02 ` Bodo Eggert
2005-09-07 10:17 Budde, Marco
2005-09-07 18:52 ` Lee Revell
2005-09-06 11:23 Budde, Marco
2005-09-06 11:30 ` Bernd Petrovitsch
2005-09-06 21:08   ` Chris Frey
2005-09-07  6:39     ` Bernd Petrovitsch
2005-09-06 11:38 ` linux-os (Dick Johnson)
2005-09-06 21:20 ` Jesper Juhl
2005-09-06 22:20   ` Esben Nielsen
2005-09-06 22:22     ` Randy.Dunlap
2005-09-06 22:32     ` Jesper Juhl
2005-09-07  2:33     ` Valdis.Kletnieks
2005-09-07  9:21       ` Esben Nielsen
2005-09-07 10:11         ` Valdis.Kletnieks
2005-09-07 10:58           ` Esben Nielsen
2005-09-07 11:44         ` Bernd Petrovitsch
2005-09-06 21:41 ` Sam Ravnborg
2005-09-10 12:29 ` Sam Ravnborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1126087207.24425.55.camel@tara.firmix.at \
    --to=bernd@firmix.at \
    --cc=budde@telos.de \
    --cc=jesper.juhl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=simlo@phys.au.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®