Natives C++ und die Verwendung in Betriebssystemen

volkard schrieb:

Aber es laufen zu viele C++-Deppen rum, die man nicht an einem Kernel herumschrauben lassen sollte, weil sie Kotz-Code schreiben.

Kannst du mal definieren was C++-Kotz-Code ist?

<D|-< schrieb:

volkard schrieb:

Aber es laufen zu viele C++-Deppen rum, die man nicht an einem Kernel herumschrauben lassen sollte, weil sie Kotz-Code schreiben.

Kannst du mal definieren was C++-Kotz-Code ist?

Wer sich mit C++ strikt an die Objekt Orientierung hält und Datenkapselung einsetzt (also setter getter Methoden implementiert usw.), der schreibt zwar gut wartbaren Code, aber der Code ist auch langsam gegenüber dem, was mit Zeigerarithmetik möglich wäre.

skaselbat schrieb:

In welchem großen Betriebssystem wurden den C++ verwendet?

AFAIK in Haiko, dem BeOS Plagiat.

volkard schrieb:

Auf den Punkt gebracht:
http://twitter.com/#!/ID_AA_Carmack/status/26560399301

Oder:
Bjarne Strousoup: "In C kann man sich leicht ins Bein schiessen. In C++ ist es schon schwerer, aber wenn, dann ist das ganze Bein weg!"

cooky451

Kenner des Grundes schrieb:

<D|-< schrieb:

volkard schrieb:

Aber es laufen zu viele C++-Deppen rum, die man nicht an einem Kernel herumschrauben lassen sollte, weil sie Kotz-Code schreiben.

Kannst du mal definieren was C++-Kotz-Code ist?

Wer sich mit C++ strikt an die Objekt Orientierung hält und Datenkapselung einsetzt (also setter getter Methoden implementiert usw.), der schreibt zwar gut wartbaren Code, aber der Code ist auch langsam gegenüber dem, was mit Zeigerarithmetik möglich wäre.

Nö. Getter und Setter werden wegoptimiert. Die Probleme sind viel einfacher. Dadurch, dass man bei C++ schnell mal eine Kopie anlegt, ohne groß nachzudenken (operator = sei Dank), entstehen hier und da gerne mal Performancefallen. C++ begünstigt halt unnötige Kopien, während man in C gleich Speicher anfordern und eine Funktion aufrufen muss.

void foo(const std::string& s)
{
  std::string s2 = s;
}

// Äquivalent zu

void foo(const char* s)
{
  char* s2 = malloc(strlen(s) + 1);
  if (s2)
  {
    strcpy(s2, s1);
    free(s2);
  }
}

An sich wäre das ja unproblematisch, die zweite Möglichkeit wird nicht viel schneller sein als die erste. Performanceprobleme entstehen aber, wenn man beispielsweise gar nicht den ganzen String hätte kopieren müssen, sondern nur einen Teil. Dass dieses Vorgehen dann hier nicht sinnvoll ist, fällt in C natürlich sofort auf, aber in C++ sieht man das schon schwerer. ("Ist ja nur ein = ")

Und ähnliche Probleme ergeben sich, wenn man eigentlich auf dem Stack arbeiten und sich die Speicherreservierung vom Heap sparen könnte. (z.B. ein immer 100 byte großer vector<char> der in einer Schleife zerstört und wieder reserviert wird.)

cooky451 schrieb:

void foo(const std::string& s)
{
  std::string s2 = s;
}

// Äquivalent zu

void foo(const char* s)
{
  char* s2 = malloc(strlen(s) + 1);
  if (s2)
  {
    strcpy(s2, s1);
    free(s2);
  }
}
An sich wäre das ja unproblematisch, die zweite Möglichkeit wird nicht viel schneller sein als die erste. Performanceprobleme entstehen aber, wenn man beispielsweise gar nicht den ganzen String hätte kopieren müssen, sondern nur einen Teil. Dass dieses Vorgehen dann hier nicht sinnvoll ist, fällt in C natürlich sofort auf, aber in C++ sieht man das schon schwerer. ("Ist ja nur ein = ")

Was soll das jetzt sein? Code der nichts sinnvolles macht sieht in C länger aus? Wo ist das "nur einen Teil kopieren"?

krümelkacker

volkard schrieb:

Auf den Punkt gebracht:
[url=http://twitter.com/#!/ID_AA_Carmack/status/26560399301]
http://twitter.com/#!/ID_AA_Carmack/status/26560399301[/url]

Volle Zustimmung.

Und nachdem ich Linus’ C++ Hass-Tirade gelesen hatte, lud ich mir mal den Kernel Quellcode und den Git Quellcode runter. Das ist für C-Verhältnisse recht gutes C, auch relativ objektorientiert sogar teilweise mit „Destruktor-Emulation“ In Git ist mir noch die Buffer-Datenstruktur aufgefallen. Mein Fazit soweit: Spätestens mit C++11 kann man die Funktionalität exakt aber um einiges eleganter dank Move-Semantics in C++ abbilden („exakt“ im Sinne der Performanz).

krümelkacker schrieb:

volkard schrieb:

Auf den Punkt gebracht:
[url=http://twitter.com/#!/ID_AA_Carmack/status/26560399301]
http://twitter.com/#!/ID_AA_Carmack/status/26560399301[/url]

Volle Zustimmung.

Und nachdem ich Linus’ C++ Hass-Tirade gelesen hatte, lud ich mir mal den Kernel Quellcode und den Git Quellcode runter. Das ist für C-Verhältnisse recht gutes C, auch relativ objektorientiert sogar teilweise mit „Destruktor-Emulation“ In Git ist mir noch die Buffer-Datenstruktur aufgefallen. Mein Fazit soweit: Spätestens mit C++11 kann man die Funktionalität exakt aber um einiges eleganter dank Move-Semantics in C++ abbilden („exakt“ im Sinne der Performanz).

Also ist C++ "nur" 20 Jahre zu spät soweit, dass man es verwenden kann.

thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

Linus about C++ schrieb:

thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

Jetzt versteh ich was volkard will und das Problem das Linux und C++ Fanboys haben.

volkard schrieb:

skaselbat schrieb:

Wurde in Windows in Linux nicht nur C und Assembler eingesetzt?

Bei Linux sind das aber andere als rein technische Gründe.

http://lkml.indiana.edu/hypermail/linux/kernel/0604.3/0964.html

*rant*

Linus about C++ schrieb:

thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918

Reaktion?

Linus about C++ schrieb:

volkard schrieb:

skaselbat schrieb:

Wurde in Windows in Linux nicht nur C und Assembler eingesetzt?

Bei Linux sind das aber andere als rein technische Gründe.

http://lkml.indiana.edu/hypermail/linux/kernel/0604.3/0964.html

The real problem with C++ for kernel modules is:

- the language just sucks. Sorry, but it does.

tntnet

Kenner des Grundes schrieb:

<D|-< schrieb:

volkard schrieb:

Aber es laufen zu viele C++-Deppen rum, die man nicht an einem Kernel herumschrauben lassen sollte, weil sie Kotz-Code schreiben.

Kannst du mal definieren was C++-Kotz-Code ist?

Wer sich mit C++ strikt an die Objekt Orientierung hält und Datenkapselung einsetzt (also setter getter Methoden implementiert usw.), der schreibt zwar gut wartbaren Code, aber der Code ist auch langsam gegenüber dem, was mit Zeigerarithmetik möglich wäre.

C++-K-Code wird von Leuten geschrieben, die meinen, Datenkapselung sei langsam und Zeigerarithmetik viel sinnvoller. C++ ist halt gerade deshalb so grossartig, weil man Abstraktion (z.B. durch getter und setter) ohne Overhead (durch inlining ovn gettern und settern) bekommt, ohne dass man diese fehleranfällige und schlecht wartbare Zeigerarithmetik verwenden muss.

Aber Volkards Link ist grossartig. Da kann ich nur voll zustimmen. Mit C++ lässt sich viel schlechterer Code schreiben, als mit den meisten anderen Programmiersprachen. Aber auch viel besserer, wenn man das entsprechende Know-How mitbringt. Es laufen einfach zu viele Anfänger rum, die sich C++ Profis nennen. Und mehrere Jahre C++-Erfahrung bedeutet nicht zwangsweise, dass einer ein guter C++-Programmierer ist.

I find C++ developing way more orgainzed than C

volkard

tntnet schrieb:

Es laufen einfach zu viele Anfänger rum, die sich C++ Profis nennen. Und mehrere Jahre C++-Erfahrung bedeutet nicht zwangsweise, dass einer ein guter C++-Programmierer ist.

Heute in diesem Forum gelesen: "Ich habe lange genug Informatik studiert, um hier fachliche Lösungen geben zu können." höhö
~(War zwar C, aber diese Art Anfänger sind es wohl.)~

314159265358979

Manchmal wäre ich zu gerne Leiter der Programmierabteilung eines Unternehmens oder wie man sowas nennt. Denen würde ich auf die Finger klopfen, bis sie kündigen

314159265358979 schrieb:

Manchmal wäre ich zu gerne Leiter der Programmierabteilung eines Unternehmens oder wie man sowas nennt. Denen würde ich auf die Finger klopfen, bis sie kündigen

Und wen stellst du stattdessen ein? Ist ja nicht so, als würden sich auf eine Stellenausschreibung dutzende wirklich Fähige melden. Genau null in der Regel, es sei denn du bist Google oder Microsoft.

Und halbwegs gut ist oft auch gut genug. Lieber ein mittelmäßiges Produkt als gar keins

314159265358979 schrieb:

Manchmal wäre ich zu gerne Leiter der Programmierabteilung eines Unternehmens oder wie man sowas nennt. Denen würde ich auf die Finger klopfen, bis sie kündigen

Bei soviel falschem Zeug wie du hier schreibst, würden die wohl dir auf die Finger klopfen.

C++ ist praktisch für größere Projekte defacto nicht zu gebrauchen.

Gute C++ Entwicklung ist extrem teuer, da es kaum jemand wirklich gut kann. Es lohnt sich daher nur für Projekte wo viel Geld zu verdienen ist. Kaum ein Entwickler wird heute noch freiwillig C++ einsetzen wenn er kleine bis mittlere Projekte für einen "normalen" Kundenkreis entwickelt.

Ein Projekt heute noch in C++ zu starten ist grob fahrlässig, da es auch hier extrem schwer werden wird das Projekt weiterzupflegen, denn immer weniger Entickler haben Lust sich jahrelang mit C++ auseinander zu setzen, bis sie irgendwann mal vielleicht so weit sind um dort wirklich professionell weiterentwickeln zu können.

Wenn es aus Performancegründen nicht anders geht ist C++ "in Ordnung", aber ansonsten Finger weg davon!!! Es gibt sooo viele bessere Werkzeuge heute, die 99% aller Anwendungsfälle abdecken.

Achso, ich beschäftige mich auch mit C und C++ ab und an ganz gerne, aber mehr aus nostalgischen Gründen. Ich würde nie wirklich ein mir wichtiges Projekt damit starten, because man braucht sich diesen Krampf heute zum GLück nicht mehr wirklich antun.