All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Holler <holler@ahsoftware.de>
To: Austin S Hemmelgarn <ahferroin7@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>
Cc: "Borislav Petkov" <bp@alien8.de>,
	"Måns Rullgård" <mans@mansr.com>,
	"Steven Rostedt" <rostedt@goodmis.org>,
	"Christopher Barry" <christopher.r.barry@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: OT: Open letter to the Linux World
Date: Thu, 04 Sep 2014 20:11:11 +0200	[thread overview]
Message-ID: <5408AB3F.4010803@ahsoftware.de> (raw)
In-Reply-To: <5408A84C.1090806@gmail.com>

Am 04.09.2014 19:58, schrieb Austin S Hemmelgarn:
> On 2014-09-04 13:29, Alexander Holler wrote:
>> Am 04.09.2014 16:36, schrieb Austin S Hemmelgarn:
>>> On 2014-09-04 06:16, Alexander Holler wrote:
>>>>
>>>> It's a myth that C++ ends up in bigger code than C. At least in my
>>>> experience. Especially when the latest additions to C++ are in effect
>>>> (like the move-semantics in C++11 I like quiet a lot and which you get
>>>> almost for free (by changing nothing) when you use the STL). Thread
>>>> support is now also standardized (in C++11), quiet nice to use.
>>
>>> Assuming you are writing in a standalone environment (no standard
>>> libraries), then yes, your code will usually be about the same size
>>> (unless you go way overboard with the object-oriented stuff); but the
>>> runtime is larger in almost all non-standalone environments, and there
>>> are some cases that code does end up larger in C++.  A lot of 'Clean C'
>>> (stuff written so that it compiles correctly as C, C++ and Objective C)
>>> that I have seen seems to end up larger (by about 4-6%) when built as
>>> C++ (although it usually does much worse as Objective C).
>>
>> There are always corner cases and I never would use some "Clean C" code
>> to compare sizes of C and C++. There is a whole lot of stuff you just
>> can't, shouldn't or wouldn't do when using C instead of C++.
>>
>> And just throwing in some numbers without any explanation about features
>> (like exceptions), optimizations and so on you've enabled for the tests
>> you used to get those numbers, doesn't work. ;)
>>
>> I can't really comment on what you mean with "standalone environment" or
>> "non-standalone environment", as I don't know what you mean with that.
>> But if several programms share e.g. the stuff which is in libstdc++.
>> you'll get a lot of size back when compared with C-only programms where
>> everyone invents the wheel again and again.
> By standalone environment, I mean no libraries, no libc[++], no external
> dependencies, and in the case of a lot of kernel programming, no
> built-ins.  A OS kernel HAS to be written like that, and it's easier to
> do that in C than C++.  I doubt that you have ever looked at any source
> code for Windows drivers, but Windows is written in C++, and they still
> are just as mind-numbingly insane as some of the poorly maintained,
> vendor originated Linux drivers.

I've seen drivers for Windows and for OS2/2 and DOS and FreeBSD and ...

But throwing the ball back, did you know that all Arduino SW is in C++? ;)

> Not all C is like the Linux kernel, and in fact, if you use Linux,
> probably more than half of your user-space programs were written in C.
> They use dynamic linking just like C++ programs (but often with less
> complex symbol mangling).

This thread isn't about the kernel, but some userspace program which 
does quiet a lot and which wants to do even more. I've just used one 
example I did in the kernel space to explain what I miss when I'm using 
or having to use C instead of C++.

I do understand why the Linux kernel is (still) in C and don't want to 
start a discussion about that.

Regards,

Alexander Holler

  reply	other threads:[~2014-09-04 18:11 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-12 19:38 OT: Open letter to the Linux World Christopher Barry
2014-08-12 20:21 ` Steven Rostedt
2014-08-12 20:44   ` Borislav Petkov
2014-08-12 22:07   ` Måns Rullgård
2014-08-13  8:27     ` Peter Zijlstra
2014-08-13  9:00       ` Borislav Petkov
2014-08-18 18:15         ` Alexander Holler
2014-09-04  7:54           ` Peter Zijlstra
2014-09-04 10:16             ` Alexander Holler
2014-09-04 14:36               ` Austin S Hemmelgarn
2014-09-04 17:29                 ` Alexander Holler
2014-09-04 17:58                   ` Austin S Hemmelgarn
2014-09-04 18:11                     ` Alexander Holler [this message]
2014-09-04 18:27           ` Rogelio Serrano
2014-09-04 18:33             ` Alexander Holler
2014-09-04 19:18               ` Rob Landley
2014-09-05  6:31                 ` Alexander Holler
2014-09-06 20:01                   ` Alexander Holler
2014-09-06 23:44                     ` Lennart Sorensen
2014-09-07  1:42                       ` Alexander Holler
2014-08-13  9:24       ` Måns Rullgård
2014-08-13  9:31         ` Peter Zijlstra
2014-08-13  9:37           ` Måns Rullgård
2014-08-13  9:37       ` Martin Steigerwald
2014-08-13  9:52         ` Peter Zijlstra
2014-08-13  9:59           ` Martin Steigerwald
2014-08-13  9:54         ` Peter Zijlstra
2014-08-13  9:57         ` Måns Rullgård
2014-08-13 10:21           ` Martin Steigerwald
2014-08-13 20:19       ` William Pitcock
2014-08-14  1:08 ` Robert Hancock
2014-08-15 18:41 ` Jaswinder Singh
2015-04-08 13:12 ` Denys Vlasenko
2015-04-09  0:37   ` Rob Landley
2015-04-09 18:18     ` Denys Vlasenko
2015-04-10 12:40     ` Rogelio M. Serrano Jr.
2015-04-10 21:20     ` Aaro Koskinen
2015-04-11  1:08       ` Rob Landley
     [not found] <E1XHxA6-0000ar-2a@feisty.vs19.net>
2014-08-15  8:59 ` Vlad Glagolev
2014-08-15 14:04   ` Gene Heskett
2014-08-16 21:10   ` Rob Landley

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=5408AB3F.4010803@ahsoftware.de \
    --to=holler@ahsoftware.de \
    --cc=ahferroin7@gmail.com \
    --cc=bp@alien8.de \
    --cc=christopher.r.barry@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mans@mansr.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.