c++ const nightmare, specially used in pointers.

[ggodw000]

I am studying c++ concurrency and it is in c++, this required me to brush up on c++ basics since I haven't touched for ~10 years. Most of them refreshed well but was taken aback by how much extra topic involved compared to c.

const usage in pointers appears lame:

usage with normal variable not pointer:

Code: Select all

const int <varname> = <value>;

means <value> can not be changed.

By the same token, you'd expect

Code: Select all

const int  *<varname> = &<variable>; 

would disallows address of <variable> from changing, but no, declaration like this allows &<variable> to change but not the data pointed by <varName>

Code: Select all

const int * <varname> = &<variable>;
<varname> = &<variable-1>; // OK allowed.
*<varname> = <value-1> ; // not allowed, compiler error.

Then you'd think

Code: Select all

int * const <varName> = &<variable>;

will allow address to be changed but not the data pointed by it but it is exactly opposite!

[alexfru]

How does your “const * int varname” even compile??? Care to provide actual code?

“const int* p” declares p as non-const pointer to const int.
“int const* p” is the same.
“int* const p” declares p as const pointer to non-const int.
“const int* const p” declares p as const pointer to const int.

See the pattern?

[Solar]

It becomes clear once you realize that the leading const in "const <type>" is the odd one out -- it's in the language for backward compatibility.

With that one exception, the rule is that "const" is always trailing whatever is being declared constant:

Code: Select all

int const i = 42; // integer constant
int const * i; // integer constant, pointer
int * const; // integer, pointer constant
int const * const; // integer constant, pointer constant

This continues into member functions:

Code: Select all

struct foo
{
    // bar() can be called on foo constant
    void bar() const;
};

As I said, "const <type>" is the exception. For consistency's sake, I never use it personally.

[alexfru]

It becomes clear once you realize that the leading const in "const <type>" is the odd one out -- it's in the language for backward compatibility.
...
As I said, "const <type>" is the exception. For consistency's sake, I never use it personally.

Speaking of backward compatibility and consistency, here's CppCon 2018: Nicolai Josuttis “The Nightmare of Initialization in C++”. When too many related concepts confuse you and spoil the language.

[Solar]

Yes, C++ would be the much cleaner language if they hadn't started from C. But I'd daresay they wouldn't have gotten as far as they did. (Compare D, Rust, ...) And "cleaner" languages have picked up their own flavor of cruft over time as well.

But that presentation also shows a positive side: They learn, and the language evolves. C++17 has come a long way from its humble origins.

[Antti]

I have mostly ignored C++ altogether. Years ago I read Linux discussions on this topic and their reasonings seemed to be logical. I know that some of those were a bit exaggerated and applicable to low-level code only. Nevertheless, I really liked the idea that in theory I could have my own compiler for my operating system project and with C++ that dream seemed to be very unrealistic.

The biggest challenge would be to change the way of thinking if I switched to C++. Somehow it feels comfortable to write in C because the language itself does not judge the "procedural mess" programming paradigm. Also, the assembly and C are quite near each other, conceptually. Please note that I do C programming as a hobby and I fully understand that C++ could provide me with very useful features if I really needed to accomplish a task at hand. Like professional programmers have to do.

Solar, what is your opinion on Linux kernel community's position as far C++ is concerned?

[Solar]

Solar, what is your opinion on Linux kernel community's position as far C++ is concerned?

tl;dr

I don't consider the Linux kernel devs in general to be trustworthy in a language discussion, and I don't discuss technology with people when I have to doubt their word.

----

Which position, exactly? Over the years they have spouted so much nonsense on the subject that it's hard to nail down anything specific.

I think the worst part about it all is that they are dishonest. Let's take my favorite example, the LKML FAQ section 15.3. Because I'm bored, let me pick it apart for you.

Why don't we rewrite the Linux kernel in C++?

Strawman. I have never seen anyone asking for that in earnest. Ever. We'll get to what the "frequently asked question" actually is later on.

(ADB) Again, this has to do with practical and theoretical reasons. On the practical side, when Linux got started gcc didn't have an efficient C++ implementation, and some people would argue that even today it doesn't.

[WP:WHO]. "Some people would argue" is weasel wording.

Also there are many more C programmers than C++ programmers around.

For one, I challenge that claim. Secondly, how many of those "many more C programmers" are complete beginners fresh out of "C as your first programming language" -- and therefore people you do not want commiting Linux kernel patches (and tying up resources for no practical gain)?

While I, personally, recommend and teach C++ as first programming language, generally speaking C++ programmers today are usually people who are on their third, fifth, or seventh programming language and have some solid experience. Also, working with C++ does give you a better idea of how to manage your code. (See "OO programming" further down.)

But I admit that's just my gut feeling. Same as it's (ADB)'s gut feeling that the pool of C programmers is superior. Let's call this one a draw.

On theoretical grounds, examples of OS's implemented in Object Oriented languages are rare (Java-OS and Oberon System 3 come to mind), and the advantages of this approach are not quite clear cut (for OS design, that is; for GUI implementation KDE is a good example that C++ beats plain C any day).

This is a howler. Not only because you can perfectly well write C++ without going OO at all, but because later on they're boasting that the Linux kernel already is using OO techniques, just using C to implement them. (We'll get to that.)

(REW) In the dark old days, in the time that most of you hadn't even heard of the word "Linux", the kernel was once modified to be compiled under g++. That lasted for a few revisions. People complained about the performance drop. It turned out that compiling a piece of C code with g++ would give you worse code. It shouldn't have made a difference, but it did. Been there, done that.

Later on they quote Linus about this "experiment" having taken place in 1992. That's six years before the first C++ standard was ratified, and firmly pre-templates (which are, IMHO, much more defining what C++ is about than OO is)...

I'd like to see the tests they ran that gave those results, because I can't really picture how the mere switch from gcc to g++ should have any significant performance impact. But using an unpublished 25-year-old benchmark of a given pre-standard compiler as an argument against a language to this day is lame.

(REG) Today (Nov-2000), people claim that compiler technology has improved so that g++ is not longer a worse compiler than gcc, and so feel this issue should be revisited. In fact, there are five issues. These are:

• Should the kernel use object-oriented programming techniques? Actually, it already does. The VFS (Virtual Filesystem Switch) is a prime example of object-oriented programming techniques. There are objects with public and private data, methods and inheritance. This just happens to be written in C. Another example of object-oriented programming is Xt (the X Intrinsics Toolkit), also written in C.

Compare this with the earlier wholesale dismissal of OO programming (and, as I said, "C++" is not equivalent to "OO" is not equivalent to "C++").

What's important about object-oriented programming is the techniques, not the languages used.

But if the language used is actually supporting your programming paradigm with native syntactic elements, you don't have to get all tricky with "void *", partial structs, init() functions and forgetting to clean up your resources when the handle goes out of scope...

Also, no C textbook I've seen so far really goes into "OO C", gives best practices etc... so we're looking at ad-hoc-ery done in a language not actively supporting the paradigm they're using, while at the same time dissing a language that does for doing so...?!?

Should the kernel be rewritten in C++?

Strawman again, see above.

This is likely to be a very bad idea. It would require a very large amount of work to rewrite the kernel (it's a large piece of code). There is no point in just compiling the kernel with g++ and writing the odd function in C++, this would just result in a confusing mix of C and C++ code. Either the kernel is left in C, or it's all moved to C++. To justify the enormous effort in rewriting the kernel in C++, significant gains would need to be demonstrated. The onus is clearly on whoever wants to push the rewrite to C++ to show such gains.

Quoting for completeness. A discussion here would be much more about inertia to change, incremental / partial conversions etc., all of which has little to do with C++ per se.

Is it a good idea to write a new driver in C++? The short answer is no, because there isn't any support for C++ drivers in the kernel.

Circular reasoning. Hey, pal, you've been asked if it were a good idea. Which, well, implies that it is made possible. (For example by accepting the patch someone actually commited, see below.) Answering that it isn't a good idea because you're intentionally roadblocking the option is dodging the subject.

See the "header" discussion further below.

Why not add a C++ interface layer to the kernel to support C++ drivers? The short answer is why bother, since there aren't any C++ drivers for Linux.

Now he's really pulling our leg here. So it isn't a good idea to write a C++ driver because there's no support for it. And adding support for it isn't a good idea because there are no C++ drivers?

Really?

However, if you are bold enough to consider writing a driver in C++ and a support layer, be aware that this is unlikely to be well received in the community. Most of the kernel developers are unconvinced of the merits of C++ in general...

...the reasons for which, today, the FAQ has utterly failed to communicate...

...and consider C++ to generate bloated code.

Given that they're using the very same techniques that C++ compilers use to get an OO-ish architecture, just using ad-hoc-ery instead of language / compiler support, I'd really like to know what the heck he's talking about.

Also, it would result in a confusing mix of C and C++ code in the kernel.

Err... no. No C++ programmer is "confused" by a mix of C and C++. And a non-C++ coder will not be looking at my C++ driver source. Please walk on, nothing to see here.

Any C++ code in the kernel would be a second-class citizen, as it would be ignored by most kernel developers when changes to internal interfaces are made.

Actually, kernel developers ignore you anyway when they make changes to internal interfaces. This happened over and over again. Madwifi. Xorg / XFree86. Some graphics chip driver I cannot remember the name of anymore. Just to name three instances where I, personally, was hit by a case of "we've changed the interface and now the associated driver / support code doesn't work anymore".

Their answer, then and now, always was "bugger the maintainer or fix it yourself". Drivers are second-class citizens.

And now they claim that they would... I don't know... ignore you more when your code is in C++? How would that look like, exactly?

A C++ support layer would be frequently be broken by such changes (as whoever is making the changes would probably not bother fixing the C++ code to match), and thus would require a strong commitment from someone to regularly maintain it.

I snigger at how he seems to be under the impression that such a "support layer" would be something that would require a "strong commitment", when it's basically just about the following (because, honestly, no-one is asking for exception handling or RTTI at this point).

Can we make the kernel headers C++-friendly?

This is what people have actually asked for. They want to write a driver, and they want to write it in C++. They can't, because the Linux headers use C++ keywords. They ask this to be changed, so they can write their driver -- which will be up to them to maintain -- in the language they want to maintain. They're disenfranchised.

And the arguements get outright ridiculous.

This is the first step required for supporting C++ drivers, and on the face seems quite reasonable (it is not a C++ support layer). This has the problem that C++ reserves keywords which are valid variable or field names in C (such as private and new). Thus, C++ is not 100% backwards compatible with C. In effect, the C++ standards bodies would be dictating what variable names we're allowed to have. From past behaviour, the C++ standards people have not shown a commitment to 100% backwards compatibility. The fear is that C++ will continue to expand its claim on the namespace. This would generate an ongoing maintenance burden on the kernel developers.

Let's have a look at that "ongoing maintenance burden". C++11 added:

• alignas, alignof, char16_t, char32_t, constexpr, decltype, noexcept, nullptr, static_assert, thread_local

C++20 will add:

• char8_t, concept, consteval, requires

Yea... terrible. Good thing that the C standard namespace doesn't expand, hm?

C99:

• inline, restrict, _Bool, _Imaginary, _Complex

If you're using the convenience macro includes in <stdbool.h> and <complex.h>, then "bool", "complex" and "imaginary" are off-limits as well. The types (char16_t, char32_t) are standard typedefs you should also stay away from in C.

C11:

• _Alignas, _Alignof, _Atomic, _Generic, _Noreturn, _Static_assert, _Thread_local

These with the convenience macros alignas, alignof, atomic_bool, atomic_int, (...), noreturn, static_assert, and thread_local.

I rest my case. But (REG) doesn't, so...

Note that someone once submitted a patch which performed this "cleaning up". It was ~250 kB in size, and was quite invasive. The patch did not generate much enthusiasm.

Someone did the work. (So much for the "Eric claim" further down that says it cannot be done in reasonable time.) But they were "meh" about it, because then they'd lose one of their main arguments about not "allowing" C++ drivers or C++ code in general -- the technical impossibility. Figures.

Apparently, someone has had the temerity to label the above paragraph as "a bit fuddy". So Erik Mouw did a short back-of-the-envelope calculation to show that searching the kernel sources for possible C++ keywords is a nightmare. Here is his calculation and comments (dates April, 2002):

This Erik then does a line count on the sources (all the sources, not just the headers...), and then does "calculations" assuming that you'd step through those sources manually looking for C++ keywords, taking 5 seconds per line.

He then makes a remark that you would need to write "a *very* intelligent search-and-replace tool for [automating] that".

You know what? All I need to write is one regex that makes Vim jump to the next potential keyword candidate... of which there are... wait a second... 132128 lines in today's kernel... which is two orders of magnitude less already, and could probably be further reduced significantly by better filtering and automatic handling of recurring cases.

Instead of pointing that out, (REG) goes on to paint a bleak picture of what would happen if you "just compile with C++ and fix all compiler errors".

At which point I believe they are intentionally trying to sell us for fools.

My personal view is that C++ has its merits, and makes object-oriented programming easier. However, it is a more complex language...

That's the second morsel of truth in the whole section, the first having been that a rewrite of the whole kernel would be a momentous undertaking for comparatively little (short-term) gain. But that's not what we're discussing here, we're talking about starting a project in C++ or not.

...and is less mature than C.

Depending on what you call "mature". Being the older language, and having a (much) smaller feature set, in a way C can't help but being more "mature". Obsolete and inconvenient would be other adjectives one could use.

The greatest danger with C++ is in fact its power. It seduces the programmer, making it much easier to write bloatware. The kernel is a critical piece of code, and must be lean and fast. We cannot afford bloat. I think it is fair to say that it takes more skill to write efficient C++ code than C code. Not every contributer to the linux kernel is an uber-guru, and thus will not know the various tricks and traps for producing efficient C++ code.

Again, at first glance this sounds like it makes perfect sense. But given that the structure of the kernel code is already mostly OO, and that things like initialization, inheritance, and destruction are done in an ad-hoc manner... somehow I doubt that the risk for bloat is so much less. In the end, bloat happens when someone writes sub-par utility code that is then used in a sub-optimal way. This happens regardless of the language involved. And C++'s capability to write good utility code should be beyond doubt by today.

On the contrary, I think it takes an uber-guru to make sense of the Linux kernel's C plumbing, especially when you are not also a C++ coder who has a mental picture of "virtual table" etc. to superimpose on it. We call these uber-gurus "kernel devs". It shouldn't take a training in "WTF is this s***?" up front to do kernel work.

The section ends with a statement by the head troll, Mr. Torvalds himself:

The fact is, C++ compilers are not trustworthy.

What?

• the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.

Agreed, as far as kernel space is concerned. Don't use it. End of story.

• any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.

Neither the compiler nor the language do hide memory allocations. A couple of the classes in the standard library do. But then, so does fopen(). The most important thing that proper C++ "hides" is the need to free those resources (and the resource leak if you don't)...

• you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is either

(a) looking for problems
(b) a C++ bigot that can't see what he is writing is really just C anyway
(c) was given an assignment in CS class to do so.

Feel free to make up (d).

So, bottom line: What the Linux kernel devs are giving you are lots of (outdated) opinion and self-contradictory or circular reasoning.

Or, to put it differently, lies, damn lies, and propaganda.

That's not the basis I'd like to discuss pro's and con's of languages on, just like I don't discuss pro's and con's of git vs. SVN with the git crowd. You get your intelligence insulted and cussed at, but you can't get them to sit down and actually talk specifics. They just repeat what they've talked themselves into believing.

[Antti]

It is hard for me to believe that Linux kernel developers were that wrong regarding the programming language issues. It would sound a bit extremist. I do believe that almost all of the analysis above is technically correct but what could be the real reason for them to deny the facts? The later discussions in 2007, when git was new, still argued against C++ but the social aspect was more highlighted. It was implied that C programmers simply have a better taste, i.e. the language and its merits were not actually the main question. It goes without saying that those kind of arguments are quite weak.

C++ is an interesting language and you clearly had an opinion on the topic. Thanks for the extensive reply, I learned new things! It seems to be possible to go from C to C++ but not vice versa so it is better to stay at C for now. More possibilities to go forward, e.g. the C++ programming language is always an option.

[Solar]

Generally speaking, Mr. Torvalds always hat a bit of an elitist and belligerent attitude [1], and both his "camps" (Linux and git) took up that attitude eagerly. It did make both projects successful, but so did the attitude of Microsoft for their products -- which, you will agree, says little about the technical value of either.

For a discussion, I prefer a contact that is willing to acknowledge my side of the argument, presenting his side in a matter-of-fact way, and can accept that I disagree without calling me names about it. Insofar, I put hardcore GPL advocates, git evangelists and Jehova's Witnesses in the same group: "Nah thanks, I'm busy".

The occasional rant notwithstanding.

----

[1]: Calling the Subversion developers present at a presentation about git "idiots" for their design choices is another one of my favorites. I handle Mr. Torvalds the same I do handle Mr. Gates: Deserving respect for their success, but not admiration for their achievement or leadership. That, I reserve for people like Jay Miner.

[alexfru]

On C++ in the kernel...

I can see how C++ could improve a thing or two. Or three.

And, clearly, ridding the headers of the reserved words is not such a big deal.

I wouldn't expect equivalent C++ code magically being compiled into something noticeably worse than the original C code these days. Dunno, maybe they need to throw in a few compiler switches to prevent the compiler from generating exception-aware code if they aren't going to use C++ exceptions anyway.

But converting the whole thing to C++ is still quite a bit of work, which won't happen by itself, and at the moment nobody dares to take a lead. And some of the community members may not like the goal, which is not very conducive for the journey towards it.

As I see it, allowing and supporting C++ in the kernel would require some serious changes, likely more on the people side than on the code side. Someone would need to learn this C++ thing at last. Someone would need to show by example how to do it right without writing in C in C++ and without writing in Java in C++ (or however you call that feared "bloat" thing). C++ really is more complex and confusing than C, so much so there's natural friction to adopting it in its entirety (barring exceptions and careless object creation and copying). Perhaps, they could think of a compiler-restricted subset? But is it possible to exclude some undesirable X without losing some desirable Y, which may happen to be implemented in terms of X? And then, the compiler changes to make it happen.

Dunno, it's not impossible. But it's not free or without problems.

[Solar]

That (rewriting Linux in C++ or not) was not really my point. My point is that the Linux kernel maintainers have a history -- a pretty consistent history -- of mixing up their personal opinion, belief, and preferences, the inertia of a million-LOC code base, and a handful of gleeful vilification[1] into an unsavory soup, without ever actually touching on the subject of discussing the pro's and con's of the languages.

They are not discussing the languages. They are defending their entrenched positions, and they do it by whatever means they deem necessary.

I didn't want to use the words "fake news" in there, because... well, because. But you get what I mean: There is so much dodging the actual subject going on there that I won't take the occasional appearance of an actual point of criticism in what they say as a starting point for discussing the language.

Disabling exception handling and RTTI is easy. Checking at compile-time whether a given type fulfills certain criteria like "is trivially copyable" to ensure you are not running into hidden costs e.g. in copying objects in generic code is easy. There are many ways you could argue that "for my project C is the better choice than C++". I'm interested to hear them. I might very well agree with you if your arguments are solid, because I am well aware that C++ is not the end-all, be-all. I just dig in my heels when people start with blanket statements and then back them up with... not much actually, while giving the impression that their command of C++ -- or rather lack of it -- might be at least partially driving their motivation.

Similar reasoning applies when people approach a discussion about C++ coming from what the Google Style Guide says.



----

[1]: The clip is "Neal is back" from the TV series "The Newsroom". SFW, with a topical message.

[xenos]

I wouldn't expect equivalent C++ code magically being compiled into something noticeably worse than the original C code these days.

My experience with the latest g++ is that with -O3 enabled (and careful checks to prevent UB) at least that part of the code which I have checked (which is the most performance critical, and actually makes use of C++ features) compiles into really efficient machine code. This might not be the case for really complex code - but that will stay out of performance critical sections anyway.

[GeGuNa]

int *p = new int[3];

p[0] = 1; p[1] = 2; p[2] = 3;

int* const &a = p;

a[0] = 15;

cout << a[0] << endl; // 15
cout << a[1] << endl; // 2
cout << p[0] << endl; // 15

string s = "test";
string* const &r = &s;
string* const a = &s;

s = "qa";
*r = "qa";
*a = "qa";

[Solar]

Turning the intentionally obtuse syntax into something resembling modern code, that turns into:

Code: Select all

#include <iostream>
#include <array>
#include <string>

using namespace std;

int main() {
    array< int, 3 > p{ 1, 2, 3 };
    auto & a = p;
    a[0] = 15;
    
    cout << a[0] << endl; // 15
    cout << a[1] << endl; // 2
    cout << p[0] << endl; // 15

    string s{ "test" };
    auto & r = s;
    auto & q = s;
    
    s = "qa";
    r = "qa";
    q = "qa";
}

...and your point is...?

[nullplan]

I will admit, without reservation, that some of these arguments against C++ are weak. Actually, some shockingly so. Some are so weak that I wonder how any intelligent person could have brought them. But some of your counters were also pretty weak. For example:

Let's have a look at that "ongoing maintenance burden". C++11 added:

alignas, alignof, char16_t, char32_t, constexpr, decltype, noexcept, nullptr, static_assert, thread_local


C++20 will add:

char8_t, concept, consteval, requires


Yea... terrible. Good thing that the C standard namespace doesn't expand, hm?

C99:

inline, restrict, _Bool, _Imaginary, _Complex


If you're using the convenience macro includes in <stdbool.h> and <complex.h>, then "bool", "complex" and "imaginary" are off-limits as well. The types (char16_t, char32_t) are standard typedefs you should also stay away from in C.

C11:

_Alignas, _Alignof, _Atomic, _Generic, _Noreturn, _Static_assert, _Thread_local


These with the convenience macros alignas, alignof, atomic_bool, atomic_int, (...), noreturn, static_assert, and thread_local.

I rest my case.

If you're paying attention, you will notice that, with the exception of inline and restrict, all of these begin with an underscore and a capital letter (unless a hitherto unknown header file is included). However, names that start with underscore and capital letter (or two underscores) are defined to be reserved for the implementation. And therefore, conforming programs could not have used these new keywords before. Therefore old programs remain compilable with new compilers, unless the code is modified to include new header files, in which case the code is already being altered, so you might as well rename the struct fields or whatever is clashing.

C++ does not make the same effort here. And let's not forget that even in C++98, there are keywords that were not present in C89, especially "class". You don't know how often a variable named "class" might come up until you try to compile C programs as C++.

Neither the compiler nor the language do hide memory allocations. A couple of the classes in the standard library do. But then, so does fopen(). The most important thing that proper C++ "hides" is the need to free those resources (and the resource leak if you don't)...

So they don't, do they? Why then are so many talks at CppCon about "how many memory allocations happen in this snippet?" You pass a string literal to a function expection a std::string, you get a temporary. That is an allocation (and a free afterwards, thus contributing to fragmentation) that is not explicitly requested. And besides, what do you do in a no-exception environment if allocation fails?

Not to mention that none of this is applicable, since a kernel is a freestanding environment, and no string classes exist unless you write them.

C++ hides a great many things from you (constructor calls for static objects, constructor calls for implicit conversions, which of these operators is actually an overload, which operator new is actually used here, etc.). If you follow the guidelines then these things shouldn't bite you, but... well, I have seen projects devolve before. Good programmers can write FORTRAN in any language, and C++ is no exception.

My personal argument against C++ in kernel space is actually this: C requires far less runtime support. You set the environment to freestanding, define memcpy() and memset() (as ordained by the GCC high priests *sigh*) and you're basically done. Everything else you write, you write the way you want. The entry points have to be written in assembly, anyway. C++ has a freestanding environment as well, it just requires a lot more

Though, finally I do have to break a lance for an oft-maligned C++ feature: What do you have against exceptions? As long as you have a safety net to prevent exceptions from leaving the C++ code and drop into the assembly, what could go wrong? I mean, if you already have C++, and you have the runtime support.