So /g/, why is the linux kernel written in C and not C++? Wouldn't

>>61568408
I have no clue why, but I would guess performance

>>61568408

C++ is an abomination of a language.
Linus Torvalds himself dislikes it.
It is much better, faster, and more intuitive to write an OS kernel in C, since you get direct access to low level facilities.

File: 1500785968106.jpg (74KB, 619x671px) Image search: [Google]

74KB, 619x671px

why isn't it written in holyC?

>>61568408
india -as always in such cases- has you're back

https://www.bosslinux.in/

>>61568426
linus torvalds is a moron

>>61568408
the short answer is that linus torvalds hates C++

the long answer is that C++ features are not very useful for writing kernels. C++ features are useful when you need to write generic code, e.g. libraries. the C++ std library is much, much better than cstdlib. but in a kernel, you don't write a lot of generic code

Because writing in C++ will just cause problems

>>61568426
I never understand what you guys mean when you say things like "low level facilities"

People seem to mean different things by it. What do you mean?

>>61568529

I mean, it doesn't try to create higher level abstractions, hence it gives the programmer full and granular control over what the code actually does; which is extremely useful when programming low level things such as drivers, or a kernel, and when programming time-sensitive applications.

Linus actually tried to port Linux to C++ but it turned out that the language isn't ideal for kernels.

File: cum.jpg (61KB, 797x799px) Image search: [Google]

61KB, 797x799px

>>61568489
where's your kernel?

>Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

- Torvalds' own words.

>>61568408
Because C++ is too hard for brainlets.

File: TempleOS_4.05_session.png (25KB, 640x480px) Image search: [Google]

25KB, 640x480px

>>61568408
Because he's not an Indian, OP.
He's still a nigger, though, for not writing his own fucking compiler.

Google's new kernel is 50% C and 50% C++ (with a lot of restrictions)

>>61568703
>Writing a single program in two languages

Disgusting. Google really has hired the most shitcaked peasants they could find in the slimiest corners of the third world.

>>61568408
many of the C++ features (polymorphism, for example) are implementation-dependent
by using C, the developers can know exactly what kind of machine code is being generated

>>61568435
Linus's family are commies

Do you know how crazy you have to be to be a commie in Europe?

because c++ supports so such extra stuff that the optimizer can make a lot less assumptions.

>>61568408
Linus mentioned this on an interview once.
In c++ it is hard to tell what the overhead of simple functions like kernel-level write operations are going to be due to the nature of the language.
Here he only mentions it as a way to piss off c++ devs, which is a tad autistic but still.
http://harmful.cat-v.org/software/c++/linus

>>61568494
>the C++ std library is much, much better than cstdlib
Try saying this at GDC and you'll get laughed out of the room. The STL may be (((generic))), but it's absolutely ridiculously slow.

>>61568408
If you want to use C++ for kernel dev you have to castrate C++ to a point where it's just

Can't use exceptions
templates make compile times even worse, causes binary bloat.
Name mangling is a pain for everyone trying to use the system libraries
Objects/methods and hidden virtual pointers are a pain for everyone trying to use the system libraries.
a platform you're trying to support might not have a C++(11) compiler (only a C compiler).
...

>>61568435
>>61568696
this desu
templeos/holyC is far better than that linus nigger

>>61568408
Linus is wrong and a total asshole, C++ namespaces alone could have made the development much easier. He's right though that C++ cannot force a certain style, he wants to be the dictator and everyone else should follow his rules or get smeared on LKML. Moreover C++ has runtime overhead, kernel and embedded programmers like to calculate the data structure sizes in their head to know exactly what it look like in runtime, but it's a stupid argument anyway

>>61568703
>google
>Not pajeet tier
>he key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

>>61568408
C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:

- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)

- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.

>>61568408
Because OOP breeds retards.
I've seen so many C++ programmers write so much fucking boilerplate bloat for something that could've easily been solved with a simple struct and a couple of functions.

They think programming is about "Objects & Patterns", which is the fisher price kiddy version of "Algorithms and data structures".
Turning CS into vocational java programming schools was a mistake, but universities have quotas to fill and students to milk

In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.

So I'm sorry, but for something like git, where efficiency was a primary
objective, the "advantages" of C++ is just a huge mistake. The fact that
we also piss off people who cannot see that is just a big additional
advantage.

If you want a VCS that is written in C++, go play with Monotone. Really.
They use a "real database". They use "nice object-oriented libraries".
They use "nice C++ abstractions". And quite frankly, as a result of all
these design decisions that sound so appealing to some CS people, the end
result is a horrible and unmaintainable mess.

The fact is, C++ compilers are not trustworthy. They were even worse in
1992, but some fundamental facts haven't changed:

- the whole C++ exception handling thing is fundamentally broken. It's
_especially_ broken for kernels.
- any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.
- 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.

hi

>>61568719
>>61568987
>/g/ poster
>good programmer
Pick 1

Because C++ was shit back in 1991, it wasn't standardized, it laked templates, STL and lots of other features, and was relatively slow. By the late 90s, when C++ finally became usable, Linux already had had millions of lines of C code written and dozens of C programmers working on it, so switching wasn't an option.

Besides, Linus had never actually learned C++ until he realized C++ is the only reasonable way to write modern GUI for his pet project subsurface some years ago. It didn't stop him from hating it tho, but then again, it's not hard to be hated by Linus.

Here you go:
http://harmful.cat-v.org/software/c++/linus

Linus's reply to a mail asking him about the same question.
Besides that, oriented object programming is one of these things that are used a lot, but extremely crappy.

>>61568529
Kernel mode

>>61568529

C is very close to metal (hardware).

When C was originally created it was created as high level language (at that time) but nowadays C is the lowest level language after Assembly (barely human readable) and Machine Code (unreadable for humans).

Also most of the other languages are actually implemented in C in some way or the other. So in a way the other languages (which are implemented in C) are built on top of C (which isn't actually the whole truth but you get the idea).

Because of this, C language isn't going away any time soon. I'm pretty sure that people are going to write in C in year 2050 and beyond.

Unix is C, C is Unix. C++ is gaysex.

C++ looks nice until you see the spec'.

Easier doesn't mean faster.
>why is linux written in c
>wouldn't it be much easier if it was written in javascript or python?

>>61569598
C++ is faster than C in many cases tho, thanks to templates, just google std::sort vs qsort.

>>61569630
Give exemples and post the source code

>>61569658
It's known, google it.
http://martin-ueding.de/en/articles/qsort-vs-std-sort/index.html

>>61569630
>thanks to templates
u wot mate, don't use words in their wrong place.
Besides that, the only reason qsort is slower is because it make a call through a pointer for each comparaison.
Just because an internal function was not done optimally doesn't mean the langage is slower, anyone could write a C function that runs at least as fast as the std::sort. You know why? because C++ functions are written in C...
On the other hands, there are many shitty C++ functions that are really slow, if you don't use them, you'd be writting basically C code.
Finally, C++ compiler sucks compared to the C one.

>>61569715
> Besides that, the only reason qsort is slower is because it make a call through a pointer for each comparaison.
It's because you the compiler can't inline the comparison function because it's passed via pointer and not via template.
> anyone could write a C function that runs at least as fast as the std::sort
Of course, but you can't write a *generic* sorting function what runs as fast as std::sort. If you want the same performance you have to manually write ad-hoc sorting function for every comparison function you want to use.
> Finally, C++ compiler sucks compared to the C one.
It's literally the same compilers with slightly different front-ends, m8.

>>61569715
>std-sort

isn't std-sort an implementation of introsort and not an implementation of quicksort? That's hardly a proper comparison.

>>61569789
>It's literally the same compilers with slightly different front-ends, m8.
As hard as C is to parse, C++ is an order of magnitude worse.

File: qsort.png (40KB, 574x358px) Image search: [Google]

40KB, 574x358px

>>61569796
We've been over this several times in /dpt/. The C standard doesn't say it has to be quicksort, it doesn't require the sort to be stable either. The difference in the performance is because of inlining of the comparison function, something C compiler just can't do.
>>61569817
Parsing has nothing to do with the performance of the resulting binary. Both gcc and clang translate C and C++ into the same intermediate representations before running optimizations and codegen.

>>61569874

Sure but comparing a sort whose name implies an upper bound of O(n^2) with a O(nlog(n)) sort, distorts the message no matter how much inlining you go.

>>61569925
> distorts the message
What does this even mean? Both libstdc++ and glibc implementors are free to use whatever sorting algorithm they like, and I guess they both use the best one they know. Whatever the names "imply" is irrelevant, the difference is in inlining.

>>61569976

>I guess they both use the best one they know.

What gives you that idea? qsort certainly doesn't seem to make any promises of being the fastest.

>>61570002
>"Should we make the standard sorting function as fast as possible since we can use whatever algorithm we like so millions of people who use the standard library would benefit? C++ people do it."
>"Nah, just use bubblesort, the standard allows it."
I mean, even if it was true, it would be just another argument not to use C.

>>61570045

So you agree that taking a badly defined algorithm, putting it up against a very fast sort and then going on about how c++ is faster than c is stupid. If you wanted fast you'd write your own sort.

>>61568860
>Here he only mentions it as a way to piss off c++
He's actually saying it's a way to keep shitty developers away from his software
>I've come to the conclusion that any programmer that would prefer the project to be in C++ over C is likely a programmer that I really *would* prefer to piss off, so that he doesn't come and screw up any project I'm involved with.

File: std_sort.png (62KB, 1019x380px) Image search: [Google]

62KB, 1019x380px

>>61570074
>a badly defined algorithm
How is it "badly defined"? The definition doesn't require a specific algorithm, nor does it require the algorithm to be stable. Here's C++ definition of std::sort for comparison, it's actually more strict since it defines complexity. If the implementors of qsort fail to use the best one they have it's entirely their fault.
>If you wanted fast you'd write your own sort.
So yet another argument not to use C?

>>61570145

>How is it "badly defined"?
> The definition doesn't require a specific algorithm, nor does it require the algorithm to be stable.

How indeed.


You seem to think a language is wholly defined by its standard libraries

>>61569055
His whole reply is sane and I totally agree.

>>61570188
>How indeed.
The fewer requirements the definition has, the better it is, since the implementors are free to use whatever algorithm they want, and they would want to use the best one. You can't just blame the difference in performance on different algorithms because qsort is free to use the same algorithm std::sort uses. But in any case, even if the algorithms were exactly the same, qsort would still be significantly slower because the main reason it is is inlining, something you can confirm yourself by using profilers.
>You seem to think a language is wholly defined by its standard libraries
I think that it's a bad sign if even the standard library can't get it right,

>>61568890
STL is hit or miss. Stuff like std::vector won't really be slower than managing your own flexible array with realloc, but std::unordered_map shits the bed.

As made evident by all the morons in this thread, there are a lot of people who don't understand C++, including C++ programmers. That's a good reason to keep it out, I guess.
But C++ is not a worse tool for the job. I'm also surprised by the number of people on /g/ that think C++ == OOP. There are many more things comprising the language than just classes, but even then, classes are not inherently bad, nor does using them mean one is OOP.

why not write linux in ruby/python/js won't it be much easier

>>61571600
this
C with RAII and templates is a valid way to write C++

>>61568408
>So /g/, why is the linux kernel written in C and not C++?
The answer to your question is:

>>61568426
>Linus Torvalds himself dislikes it.

The real question is, what does Linus think about Rust?

>>61569055
Replace C++ by object-oriented languages and his rant is still true.
OOP is a cancer.

>>61571699
Let me guess, you think functional programming is the panacea too?

>>61569630
>just google std::sort vs qsort
>he uses standards sorting for high performance sorting
the hell is wrong with you?
Use archi-specific algos like merge sort and derivate.

>>61571757
Nah, imperative programming is still king when you have a brain.

>>61572107
>yet another C-tard completely misses the point
It's like you guys can't read.

>>61568408
porting an entire C++ compiler to a new architecture is harder than porting a C one

>>61568426
>Linus Torvalds himself
>the Messiah said it
>everyone must embrace His opinion

>>61568446
>you're back
you're Hitler

>>61571348
Doesn't that depend on implementation ?

>>61568719
>Disgusting. Google really has hired the most shitcaked peasants they could find in the slimiest corners of the third world.
The new OS is made by the same guys who developed BeOS

>>61572180
The specification for std::unordered_map practically forces it to be implemented as a linked list.

File: LLVMCompiler1.png (21KB, 558x206px) Image search: [Google]

21KB, 558x206px

>>61572146
False. Modern compilers like gcc and clang use intermediate representations for back-ends, the difference is in the front-end only.

>>61572132
No, I totally understand, you guys are too retarded and must relly on jack of all trade algos to do things because using your brain is too hard, typical OOP-brainlet.
Yes, in this particular case c++ is better, we can find billions of other cases where c++ is faster... Exactly like we can find billions of cases where C is faster.
Both tools are good, it's up to you to judge which one is more appropriate for the task.

>>61572148
The kernel is written by linus so yes, you have to embrace his opinion because it's his kernel
when is summer over

>>61572286
Yeah, but the exact reason why C++ is faster has been explicitly stated - namely, that templates enable inlining, something a C compiler is unable to do. For some reason, C-tards keep talking about how the comparison is unfair, how algorithms are different, and how you can always write ad-hoc sorting functions for every type you have, completely missing the main point here - efficient generic sorting function is impossible in C because it lacks templates.

>>61572364
Couldn't you make a macro? It'd be awkward for sure though.

>>61572376
C macros are not nearly as expressive as templates, and without automatic type inference, you'd have a hard time. C11 _Generic will help somewhat, but you'd still have to create your own framework from scratch.

>>61572376
Maybe? You still have to have a way to pass a custom comparison function to it tho.

>>61572407
>and without automatic type inference,
as if that matters to Cfags, they're happy to pass void* and (*int)(void*) into qsort

File: ange.png (585KB, 2000x1519px) Image search: [Google]

585KB, 2000x1519px

>>61572364
http://en.cppreference.com/w/c/language/generic

>>61572998
>He thinks function overloading is generics
Also _Generic is crippled by C's garbage type system.

>>61572998
You do realize it has nothing to do with templates, right? You have to manually write code for each type you use.

>>61568408
because C++ is shit. use either C or Rust in its place