LWN.net Logo

Well, it's quite simple, really...

Well, it's quite simple, really...

Posted Jan 18, 2011 11:34 UTC (Tue) by khim (subscriber, #9252)
In reply to: Not everything is a nail... by khim
Parent article: Sobotka: Why GIMP is inadequate

Everything that can be done in C can be done at least as well in C++.

Well, this is strawman argument: of course you can just ignore all C++ extensions and then produce the same code in C++ as in C. But what's the point? If you try to use "real" C++ facilities...
$ cat hello.c
#include <stdio.h>
int hello() {
  printf("Hello, World!\n");
}
$ gcc -O3 -c hello.c ; size hello.o
   text    data     bss     dec     hex filename
     72       0       0      72      48 hello.o
$ cat hello.C
#include <iostream>

int hello() {
  std::cout << "Hello, World!" << std::endl;
}
khim@khim-glaptop:/tmp$ gcc -O3 -c hello.C ; size hello.o
   text    data     bss     dec     hex filename
    244       8       1     253      fd hello.o

Claiming that C++ would have led to a more complex and less flexible design is thus downright absurd.

Not really. Most C++ designs are indeed more flexible, but this is not a big factor for kernel development where you can always redesign anything (the infamous "stable API nonsense"), but the fact that they are "more flexible" usually means they are more complex and less efficient.

(and the code produced in C++ is usually significantly more resource-hungry and slower then code written in C)
That's outright bullshit. A key design decision in C++ has always been "don't pay for what you don't use", and it worked out pretty well in fact.

Where "pretty well" == "bloat of about factor of two or three". Yup. C++ does not impose choice on your so you end up with 4-5 implementations for basic things. Heck, C++ standard includes two different string implementations from the start (I mean "char *" and "std::string") - and different libraries like to add additional ones! And we are talking about kernel, remember? Kernel shares L1 with userspace program and it's pitiful: 64K at most. And, please, don't talk about Moore's Law here: PowerPC 601 had 32K cache 18 years ago, Intel Core2 has 32K cache today. Yeah, it's kind of "apples vs oranges" because there are two 32K caches on Core2 and PowerPC 601 and AMD's Phenom has whopping 64K L1 cache, but anyway: even two doublings per 18 years is not enough to claim that endless adapters and transformers are no longer meaningful for kernel.

The "don't pay for what you don't use" is only good when you don't use anything. When you actually do use some facilities you suddenly find out that they cost more then in case where language imposes things on you.


(Log in to post comments)

Well, it's quite simple, really...

Posted Jan 18, 2011 12:08 UTC (Tue) by dwmw2 (subscriber, #2063) [Link]

"Well, this is strawman argument: of course you can just ignore all C++ extensions and then produce the same code in C++ as in C."
Can I? In the kernel we make heavy use of C99 structure initialisation. Where structures can so often change and gain new members, it's very important to have named initialisers. But this code will fail if compiled as C++:
struct foo {
	int a;
	int oh_we_introduced_this_optional_thing_later;
	int b;
};

struct foo f = {
	.a = 1,
	.b = 2,
};
Losing that facility would introduce a lot of errors into the kernel, at a single fell stroke.

Well, it's quite simple, really...

Posted Jan 18, 2011 13:27 UTC (Tue) by foom (subscriber, #14868) [Link]

Surprisingly, it didn't even make it into C++0x.

It seems to me it'd be a reasonable extension for "gnu++0x", though.

Well, it's quite simple, really...

Posted Jan 18, 2011 18:57 UTC (Tue) by daniel (subscriber, #3181) [Link]

The lack of designated initializers in C++ is pure brain damage. I do not understand why the issue does not get more attention. That said, the old gnu syntax still works: {foo: x, bar: y} except that you have to specify the initializers in the order declared and insert nulls if you skip fields, the latter requirement serving no imaginable purpose whatsoever. But at least in this way you can protect yourself from structure field evolution. This C advantage in no way makes up for all the structuring primitives that C lacks.

Well, it's quite simple, really...

Posted Jan 18, 2011 21:07 UTC (Tue) by foom (subscriber, #14868) [Link]

It doesn't sound like brain damage, but rather a brand new (well, 12 years old now, but by C standards, brand new) feature in C that has not been ported to C++ yet. C++ adds all sorts of additional complex interactions to such a feature that would have to be properly specified...and nobody's done that yet. You could probably get a proposal accepted for C++20 (or whatever) though...

The restrictions on the GCC extension seem like someone just didn't really finish implementing it yet. I'd bet you would be welcome to do so.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds