Czemu jądro Linuksa nie zawiera kodu C++?

Cześć, mam pytanie jak w temacie zauważyłem że jadro Linuksa (pliki źródłowe które przejrzałem niezwykle pobieżnie) nie zawiera kodu pisanego tak typowo w C++ - brak tam klas chociażby a przeważa C (pomijając części kodu w asm)- moje pytanie : Dlaczego tak jest - czy C jest bliżej sprzętu niż C++a może użycie C++ uwłacza godności prawdziwego twórcy jądra systemu operacyjnego :)
Pytanie wynika stąd że ostatnio krążyć mi się zachciało wkoło tematu tworzenia modulów jądra/sterowników - w każdym razie hacking po całości - i aż mnie drażni styl pisania tego typu rzeczy - pojedyncze funkcję - niektóre o dość dziwnych nazwach , struktury, tablice char itp.

a może użycie C++ uwłacza godności prawdziwego twórcy jądra systemu operacyjnego

From: Linus Torvalds <torvalds <at> linux-foundation.org>
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 17:50:28 GMT (2 years, 14 weeks, 16 hours and 36 minutes ago)

On Wed, 5 Sep 2007, Dmitry Kakurin wrote:

When I first looked at Git source code two things struck me as odd:

1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
   it's BS.

YOU are full of bullshit.

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.

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.

But I'm sure you'd like it more than git.

        Linus

On Tue, 20 Jan 2004, Robin Rosenberg wrote:

This is the "We've always used COBOL^HH^HH" argument.

In fact, in Linux we did try C++ once already, back in 1992.

It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA.

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.

Feel free to make up (d).

Czyli jak rozumiem brak jakichkolwiek typowo technicznych przeciwwskazań ?

Przecież masz tam techniczne powody, zwłaszcza w drugim cytacie.

Ciężko jest negatywną opinię uformowaną w 1992 na podstawie transpilatora CFront uznać za powód techniczny. Linus nie lubi C++ i tyle. Jest dobrym programistą, ale bardzo silnie siedzi w swoich często kontrowersyjnych poglądach. Jak by nie patrzeć, kernel linuksa odniósł sukces i jest projektem o bardzo wysokiej jakości kodu, ale:

C++ z freestanding environment (i pewnymi ograniczeniami dotyczącymi kodowania - ale to jest też w C) jak najbardziej by mogło być użyte w kernelu z dużym pożytkiem (kernel miał kilka duplikujących się implemetnacji linked listy czy hashmapy - dopiero niedawno to poprawili, ale i tak wygląda to dość strasznie bo C jest prymitywnym językiem).

Dobrze zrozumiałem, że on uważa C++ za straszny język, ale woli C?

nie dziwie się. C++ jest straszny.

C jest językiem, w którym łatwo sobie strzelić w stopę. W C++ jest nieco trudniej strzelić sobie w stopę (np. zapominając o free), ale za to jak już się to zrobi, to urywa od razu całą nogę.

C++ daje pewne fałszywe poczucie bezpieczeństwa. Tak naprawdę można w nim popełnić wszystkie te same błędy co w C, tyle że mniej się rzucają w oczy, bo mogą być ukryte pod płaszczykiem ładnych abstrakcji. I dlatego niskopoziomowi programiści raczej wolą C, a nie C++. Po prostu w C widać jak na dłoni co się dzieje w kodzie. A to że kod jest dłuższy i trudniej go napisać, zmusza do myślenia jak upraszczać pewne rzeczy. C++ z kolei zachęca do klepania rzeczy szybko, używając wysokopoziomowych abstrakcji i gotowców, bez zdawania sobie sprawy z kosztów i zagrożeń (bo są ukryte). Kończy się tak, że chyba w Chromie bardzo duża część CPU przy renderowaniu złożonych stron idzie na alokacje pamięci pod std::string. Bo tych alokacji w kodzie nie widać. Ale są. I pożerają cykle.

Paradoksalnie nawet wielcy promotorzy i eksperci C++ mają z pisaniem poprawnego kodu w C++ problem. Np. Herb Sutters.
http://flyingfrogblog.blogspot.com/2013/10/herb-sutters-favorite-c-10-liner.html

Krolik napisał(a):

C jest językiem, w którym łatwo sobie strzelić w stopę. W C++ jest nieco trudniej strzelić sobie w stopę (np. zapominając o free), ale za to jak już się to zrobi, to urywa od razu całą nogę.

C++? free? Ręczne zarządzanie pamięcią?

Język C jest lepszym rozwiązaniem to zastosować nisko poziomowych. To taka jakby nakładka na assembler. Kod C wykonuje się szybciej. Ma się się większą kontrole nad tym co się robi, przeto lepiej i świadomie można kod zoptymalizować. W zasadzie chyba większość liczących się systemów operacyjnych jądra mają pisane w C.

Myślę że Linus ma całkowitą rację.

Jedyną słabością C jest obsługa łańcuchów, ale przy odpowiednich bibliotekach da się z tym żyć..
W C++ masz za to tyle pułapek, że trudno zagwarantować bezpieczeństwo kodu, zwłaszcza jeśli mamy do czynienia z programistą "jakoś to się napisze".
Czytając kolejne książki o C++ można nauczyć się unikać pewnych pułapek, ale nadal będzie niezerowa możliwość popełnienia błędu.
I to nie tylko ze względu na wycieki pamięci, ale też ze względu na pułapki wydajnościowe czy logiczne.

Ucząc się różnych języków widać czasami że zostały zaprojektowane (Pascal, Ada, C, Java, Python), w innych przypadkach mamy do czynienia "z językiem z ficzerami" (PHP, C++, Objective-C). W tym drugim przypadku brak odcięcia się od przodka mści się na każdym kroku.

W C++ jest tego cała masa:

• tablice zamienne na wskaźniki (tablicę można traktować czasami jak wskaźnik)
• niekontrolowane egzotyczne konwersje w locie (int na void *, bool na cokolwiek)
• przesyłanie obiektów/struktur (na N sposobów, niektóre zadziwiająco wolne, move semantic zadziwiająco skomplikowane, ukryte niekontrolowalne alokacje)
• brak kontroli alokacji przy zwracaniu wartości (jeśli przez return to może będzie RVO/NRVO a może nie)
• brak błędów kompilatora tam gdzie powinny być (zamiast tego warning: brak return, użycie niezainicjowanych zmiennych)
• brak klasy bazowej (Java - Object, OO Pascal: TObject) oraz możliwości odwoływania się do niej (super, inherited) bez dodatkowych deklaracji
• wyjątki zgłaszane przy pomocy prymitywnych wartości (choćby int) - WTF? - jak zagwarantować obsługę tego bez klasy bazowej?
• brak spójnej (automatycznej) kontroli miejsca alokacji obiektu (przesyłanie obiektu w shared memory i późniejsze jego używanie bez kopiowania)
• brak wsparcia dla przenośnego ABI (biblioteki w wersji Unicode/ANSI, wielowątkowa/nie itd., przesyłanie obiektów m. DLL-ką a programem głównym)
• brak kontroli typu dla "delete" - można zwolnić tablicę obiektów zamiast obiektu
• pułapki wydajnościowe przy literałach łańcuchowych - dopiero w C++17 może będzie string_view, póki co napis "test" nie jest typu std::string (i ile z tym jest niespodzianek?) - (1)

Dużo jest poprawione w C++11, ale myślę, że gdybym miał pisać oprogramowanie rakiet przenoszących ludzi, to choćbym miał 100 lat doświadczenia w C++ to na ten język bym się nie zdecydował.

Podsumowując
C++ jest językiem wysokopoziomowym, raczej do dużych aplikacji biznesowych/graficznych niż do obsługi przerwań czy stronicowania. Nadal jest to główny język w którym coś robię dla przyjemności, ale na pewno pisanie w nim bezpiecznego kodu nie należy do najłatwiejszych zadań.

(1) Rozwiązanie na dzisiaj: https://github.com/vpiotr/char_view

@pioflor: która z tych zalet nie tyczy się C++, który ma prawie 100% zgodności z C?

@vpiotr: pieprzysz Pan.

W C++ jest tego cała masa:

• tablice zamienne na wskaźniki (tablicę można traktować czasami jak wskaźnik)
  Jakim cudem jest to problem w C++ a w C już nie skoro występuje w obu?

• niekontrolowane egzotyczne konwersje w locie (int na void *, bool na cokolwiek)
  C++ odziedziczył ten problem po C, mimo wszystko go chociaż trochę ograniczając (Uniform Initialization, void* na T*)

Dalej wymieniasz brak rzeczy, których ani w C ani w C++ nie ma jako argument za użyciem C ponad C++. Gdzie w tym logika, gdzie sens?

W C++ jest tego cała masa:

• tablice zamienne na wskaźniki (tablicę można traktować czasami jak wskaźnik)
  No ale to zaszłość z C jest... chyba, że mówisz o referencji do tablicy, gdzie tablica to tablica i to jest takie mylące...
  Chyba też od tego jest arrayview w nowszych, ale ok, to nie zawsze jest dostępne...

• niekontrolowane egzotyczne konwersje w locie (int na void *, bool na cokolwiek)
  J/w., zaszłość z C a i tak nieco poprawiona...

• przesyłanie obiektów/struktur (na N sposobów, niektóre zadziwiająco wolne, move semantic zadziwiająco skomplikowane, ukryte niekontrolowalne alokacje)
  No fakt, ale z drugiej kwestia dobrych praktyk, w C miałeś to n nieco mniejsze...

• brak kontroli alokacji przy zwracaniu wartości (jeśli przez return to może będzie RVO/NRVO a może nie)
  No ok.

• brak błędów kompilatora tam gdzie powinny być (zamiast tego warning: brak return, użycie niezainicjowanych zmiennych)
  -Werror i inne takie. To wbrew pozorom może mieć swoje zastosowanie w lowlevelu...

• brak klasy bazowej (Java - Object, OO Pascal: TObject) oraz możliwości odwoływania się do niej (super, inherited) bez dodatkowych deklaracji
  Ok, tak rzeczywiście jest. Ale co za problem napisać classA::method() w metodzie klasy pochodnej?

• wyjątki zgłaszane przy pomocy prymitywnych wartości (choćby int) - WTF? - jak zagwarantować obsługę tego bez klasy bazowej?
  Mogą być, ale chyba raczej nie są?

• brak spójnej (automatycznej) kontroli miejsca alokacji obiektu (przesyłanie obiektu w shared memory i późniejsze jego używanie bez kopiowania)

• brak wsparcia dla przenośnego ABI (biblioteki w wersji Unicode/ANSI, wielowątkowa/nie itd., przesyłanie obiektów m. DLL-ką a programem głównym)
  ABI to w ogóle mnie boli, tak, tak, tak, to jest problem.

• brak kontroli typu dla "delete" - można zwolnić tablicę obiektów zamiast obiektu
  Od tego są vectory i smart ptry...

• pułapki wydajnościowe przy literałach łańcuchowych - dopiero w C++17 może będzie string_view, póki co napis "test" nie jest typu std::string (i ile z tym jest niespodzianek?)
  To też zaszłość z C... u mnie w robocie kochają pisać while("forever") ;)

@vpiotr popatrz z drugiej strony: zrób w C RAII bez pochodu goto cleanup albo attribute... Ja nie mówię, że nie masz racji, ale wiele z tych rzeczy to kwestia gustu/kompromisu między niskopoziomowością a abstrakcją. Nie twierdzę, że C++ jest idealny, ale w wielu miejscach sporo ułatwia.

kq napisał(a):

@vpiotr: pieprzysz Pan.

W C++ jest tego cała masa:

• tablice zamienne na wskaźniki (tablicę można traktować czasami jak wskaźnik)
  Jakim cudem jest to problem w C++ a w C już nie skoro występuje w obu?

Prosty przykład:
http://stackoverflow.com/questions/1863751/array-decay-to-pointers-in-templates

kq napisał(a):

• niekontrolowane egzotyczne konwersje w locie (int na void *, bool na cokolwiek)

C++ odziedziczył ten problem po C, mimo wszystko go chociaż trochę ograniczając (Uniform Initialization, void* na T*)

Problemy które mam na myśli nie występują w C:

• safe_bool: https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Safe_bool
• function overload (void * vs int): w C jest dopiero od C11

kq napisał(a):

Dalej wymieniasz brak rzeczy, których ani w C ani w C++ nie ma jako argument za użyciem C ponad C++. Gdzie w tym logika, gdzie sens?

To lista rzeczy która pokazuje jakie są braki w tym języku przez to że nie został zaprojektowany od nowa a jedynie rozbudowano jego przodka.
... i ogólnie rzeczy które pokazują że można się czuć fałszywie bezpiecznym w tym języku.
C jest bardziej prymitywne, więc na każdym kroku się pilnujesz, w C++ myślisz że coś robisz ale możesz się mylić (dlatego np. wprowadzono nullptr).

Właściwie wszystko już zostało napisane, ale udzielę odpowiedzi krótkiej:

Cześć, mam pytanie jak w temacie zauważyłem że jadro Linuksa (pliki źródłowe które przejrzałem niezwykle pobieżnie) nie zawiera kodu pisanego tak typowo w C++ - brak tam klas chociażby a przeważa C

Bo jest napisane w C a nie w C++.

Bardzo ładnie można to zobaczyć na przykładzie:

• C: http://ideone.com/U4lNrU - niebezpiecznie, ale łatwo zauważyć, że się dzieje coś dziwnego
• D: http://ideone.com/WxNOq9 - bezpiecznie, GC się tym zajmie
• Rust: http://ideone.com/sxTb4j - bezpiecznie, kod się nawet nie skompiluje (mutowalne referecje muszą być unikalne)
• Go: http://ideone.com/4NHvlp - bezpiecznie, podobnie jak D

Natomiast nasz bohater:

• C++: http://ideone.com/nZTYs4 - niebezpiecznie, brak warninga, program się nie wykłada (bo nie musi), tylko zwraca zły wynik O.o

EDIT: Dodałem wywołanie free w wersji C (dzięki @Azarien, dawno nic nie pisałem większego w C, skleroza po Ruscie).