Schlanke Programme mit C++

Und? Das beweist noch lange nicht, das es mit C++ weniger gut umsetzbar ist. Denn letztendlich sind die Kernel von Unixe und WinNT aus rein historischen Gründen in C implementiert. Denn C ist wesentlich länger normiert, und da man die Kernel portabel halten wollte, blieb wohl logischerweise damals nur C übrig. Denn damals war die Chance größer auf den gewünschten Platformen einen ANSI-C Compiler zu finden. Da ist es nur legitim sich für C zu entscheiden.

Was wäre, wenn heute jemand mit einem neuen OS (nein, kein Clone) anfangen würde? Ich wette, wenn derjenige kein genereller C++-Hasser ist, wird C++ sicherlich in die engere Auswahl fallen.

UnregUser schrieb:

Was wäre, wenn heute jemand mit einem neuen OS (nein, kein Clone) anfangen würde? Ich wette, wenn derjenige kein genereller C++-Hasser ist, wird C++ sicherlich in die engere Auswahl fallen.

klar, zuerst wäre c++ bestimmt unter den kandidaten, aber wenn er sich näher informieren würde, und dabei sowas findet: http://yosefk.com/c++fqa/defective.html
könnte das schon das aus für c++ bedeuten. die frage finde ich übrigens ganz interessant: 'welche programmiersprache nimmt man am besten für ein neues, grosses betriebssystem, vom kaliber eines windoofs oder unix". ich wüsste nicht welche. C, glaube ich, würde ich heute auch nicht mehr für so ein grosses projekt benutzen.

sri

Man muss nicht unbedingt alle Möglichkeiten von C++ ausreizen. Objektorientierung, bessere Typenprüfung und eine Variablendeklaration auch mitten in der Funktion bzw. im Block sind schon mal große Vorteile gegenüber reinem C. Auf Exceptions, Templates, STL und andere C++-Besonderheiten kann man ja auch verzichten.

Statt Weiß oder Schwarz einfach mal Grau in diversen Abstufungen verwenden.

sothis_

sri schrieb:

Variablendeklaration auch mitten in der Funktion bzw. im Block

das bitte aus der liste rausstreichen

Tachyon

sothis_ schrieb:

sri schrieb:

Variablendeklaration auch mitten in der Funktion bzw. im Block

das bitte aus der liste rausstreichen

Warum?

sothis_

Tachyon schrieb:

Warum?

weil das seit C99 der vergangenheit angehört.

DEvent

sothis_ schrieb:

Neugieriger schrieb:

Imho gehört zu einem Betriebssystem mehr als nur der Kernel, der alleine reicht ja nicht um das Gerät in Betrieb nehmen zu können.

und wie er das tut. sonst würde der kernel sehr unvollständig sein.

Kommt drauf an welcher Kernel. Ein monolithischer sollte wohl auch Treiber integriert haben, ein Micro-Kernel nicht.

MacOS ist in ObjectiveC geschrieben, Singularity in C# und Haiku in C++. Who cares was fuer eine Sprache fuer ein B-System verwendet wird?

Btw, C ist halt praktisch, weil C nunmal den kleinsten gemeinsamen Nenner bildet. Jede DLL oder .so kannst du in C einbinden und du kannst in jeder "hoeheren Sprache" C Bibliotheken einbinden.

Mit C++ wird es schon kompliziert, bei anderen Sprachen bist du bei Bibliotheken auf die Sprache beschraenkt (Java-jars koennen nur in Java benutzt werden, Ruby-Bibs nur in Ruby usw.).

sri schrieb:

Man muss nicht unbedingt alle Möglichkeiten von C++ ausreizen. Objektorientierung, bessere Typenprüfung und eine Variablendeklaration auch mitten in der Funktion bzw. im Block sind schon mal große Vorteile gegenüber reinem C. Auf Exceptions, Templates, STL und andere C++-Besonderheiten kann man ja auch verzichten.
Statt Weiß oder Schwarz einfach mal Grau in diversen Abstufungen verwenden.

seltsam. bei keiner anderen sprache, ausser bei c++, wird einem immer geraten: 'mach das nicht, dieses ist böse, benutze jenes nicht, nimm nur einen subset, usw...'. woran das wohl liegen mag?

DEvent schrieb:

Who cares was fuer eine Sprache fuer ein B-System verwendet wird?

na, viele. z.b. die, die am OS selber rumbasteln, oder erweiterungen dafür schreiben wollen, etc.

DEvent

fricky schrieb:

sri schrieb:

Man muss nicht unbedingt alle Möglichkeiten von C++ ausreizen. Objektorientierung, bessere Typenprüfung und eine Variablendeklaration auch mitten in der Funktion bzw. im Block sind schon mal große Vorteile gegenüber reinem C. Auf Exceptions, Templates, STL und andere C++-Besonderheiten kann man ja auch verzichten.
Statt Weiß oder Schwarz einfach mal Grau in diversen Abstufungen verwenden.

seltsam. bei keiner anderen sprache, ausser bei c++, wird einem immer geraten: 'mach das nicht, dieses ist böse, benutze jenes nicht, nimm nur einen subset, usw...'. woran das wohl liegen mag?

Liegt IMHO daran, dass C++ allen recht machen will und es eine Multiparadigmen-Sprache ist. Deswegen muss der Benutzer abwaehgen ob er wirklich die Features braucht oder ob sie mehr behindern als nuetzen.

z.B. Exceptions oder RTTI. Braucht mans, oder doch nicht? In Java stellt sich die Frage nicht, oder nur ganz selten. In C++ bringt es halt eine Menge Overhead, Java wurde darauf optimiert. In C++ bringt es viel darauf zu verzichten, in Java bringt der Verzicht einem nichts.

Tachyon

sothis_ schrieb:

Tachyon schrieb:

Warum?

weil das seit C99 der vergangenheit angehört.

C99, ja... und das haben auch so viele Compiler so richtig umgesetzt, bis jetzt...

sothis_

Tachyon schrieb:

sothis_ schrieb:

Tachyon schrieb:

Warum?

weil das seit C99 der vergangenheit angehört.

C99, ja... und das haben auch so viele Compiler so richtig umgesetzt, bis jetzt...

da konnte ich mir denken, dass jetzt sowas kommt. wer c-code mit microsoft kompilern kompiliert ist selbst schuld. nur weil microsoft es nicht _will_ dies zu unterstützen, macht das noch lange nicht den sprachstandard selbst schlecht.

tntnet

DEvent schrieb:

fricky schrieb:

sri schrieb:

Man muss nicht unbedingt alle Möglichkeiten von C++ ausreizen. Objektorientierung, bessere Typenprüfung und eine Variablendeklaration auch mitten in der Funktion bzw. im Block sind schon mal große Vorteile gegenüber reinem C. Auf Exceptions, Templates, STL und andere C++-Besonderheiten kann man ja auch verzichten.
Statt Weiß oder Schwarz einfach mal Grau in diversen Abstufungen verwenden.

seltsam. bei keiner anderen sprache, ausser bei c++, wird einem immer geraten: 'mach das nicht, dieses ist böse, benutze jenes nicht, nimm nur einen subset, usw...'. woran das wohl liegen mag?

Liegt IMHO daran, dass C++ allen recht machen will und es eine Multiparadigmen-Sprache ist. Deswegen muss der Benutzer abwaehgen ob er wirklich die Features braucht oder ob sie mehr behindern als nuetzen.

z.B. Exceptions oder RTTI. Braucht mans, oder doch nicht? In Java stellt sich die Frage nicht, oder nur ganz selten. In C++ bringt es halt eine Menge Overhead, Java wurde darauf optimiert. In C++ bringt es viel darauf zu verzichten, in Java bringt der Verzicht einem nichts.

Ja genau - in Java kann man darauf verzichten, aber es bringt nichts, da man den Ballast so oder so mitschleppt. In C++ hat man die Wahl, auf die paar Taktzyklen oder Bytes auch noch zu verzichten.

Es ist ein Trugschluss, dass es eine Menge Overhead bringt. C++ ist sehr wohl für die Embedded Programmierung geeignet. Vielleicht nicht, wenn man nur wenige kBytes zur Verfügung hat, aber schon bei ein wenig grösseren Maschinchen kann man es sehr wohl verwenden. Neulich auf dem Linux Tag in Berlin habe ich obico kennen gelernt. Die haben eine Fahrradcomputer gebaut. Und verwenden dafür natürlich C++.

C++ ist nach der Philosophie entwickelt worden, dass Du nur dafür bezahlst, was Du verwendest.

Warum ist die STL so gross? Weil sie viel bringt. In C verwendet man häufig Puffer mit fester Grösse für Strings, weil es zu umständlich ist, einen variablen zu verwenden. Ein fester Puffer ist natürlich sehr schnell und klein. Dafür handelt man sich ganz schnell Pufferüberläufe ein.

In C++ verwendet man lieber std::string, der Code mitbringt, um auf der einen Seite Pufferüberläufe vermeidet und auf der anderen Seite die Grösse der Strings nicht festlegt, sondern dynamisch macht. Realisiere ich das gleiche in C, komme ich sicher auf die gleiche Codegrösse.

Noch extremer wird es mit std::vector, da ich häufig diesen Template mit unterschiedlichen Typen verwende und der C++-Compiler für jeden Typ den entsprechenden Code instantiiert, sofern ich ihn verwende.

Auch das kann ich natürlich in C machen, aber da muss ich es zu Fuß machen und daher lieber unschöne und potentiell gefährliche Tricks verwende, um nicht so viel Code schreiben zu müssen.

Es ist halt einfach einfach, mit C++ viele Features zu implementieren. Das bedeutet natürlich mehr Code, der vom C++-Compiler erzeugt wird. Wenn man sich dessen bewusst ist, kann man mit C++ wunderbar kleine Programme schreiben.

tntnet schrieb:

Neulich auf dem Linux Tag in Berlin habe ich obico kennen gelernt. Die haben eine Fahrradcomputer gebaut. Und verwenden dafür natürlich C++.

embedded-linux ist in C geschrieben worden. ein paar, in c++ geschriebene userland-applikationen dranzustöpseln, ist nun wirklich keine innovation. zudem hat ein ARM9 normalerweise genug reserven, um durch c++ nicht ins schwitzen zu kommen.
btw: vor 10 jahren wäre das ding sicherlich messetauglich gewesen, aber heute?!?
für'n fahrradcomputer sind die ausmasse auch mehr als klobig: http://www.obico.de/images/lt08booth.jpg
ich glaube nicht, dass der obico ein kommerzieller erfolg wird.

*john 0

fricky schrieb:

klar, zuerst wäre c++ bestimmt unter den kandidaten, aber wenn er sich näher informieren würde, und dabei sowas findet: http://yosefk.com/c++fqa/defective.html
könnte das schon das aus für c++ bedeuten.

Für all diese Probleme gibt es Lösungen, bzw. sie sind aus Sicht aus höheren Programmiersprachen geschrieben. Was in Hinsicht auf Kernelentwicklung ziemlich sinnlos ist. Übrigens die meisten Probleme betreffen C in der einen oder anderen Form ebenfalls.

fricky schrieb:

die frage finde ich übrigens ganz interessant: 'welche programmiersprache nimmt man am besten für ein neues, grosses betriebssystem, vom kaliber eines windoofs oder unix".

Wenn man die Liste der potentiellen Kandidaten durchgeht und einige Anforderungen stellt bleiben ziemlich schnell nur zwei Sprachen übrig: Ada und C++. Bei allen anderen fehlen die notwendigen Compiler, es fehlt eine Normierung etc. oder man landet wieder bei C.

Xantus

DEvent schrieb:

MacOS ist in ObjectiveC geschrieben, Singularity in C# und Haiku in C++. Who cares was fuer eine Sprache fuer ein B-System verwendet wird?

Nene...so stimmt das nicht ganz ..

MacOS setzt bekanntlich auf Darwin auf - ist somit größtenteils in C geschrieben, als echtes Unix unter der Bonbonoberfläche. Und im Vergleich allerdings zu anderen Unix-like Systemen (*BSD, Solaris, Linux) setzt MacOS sogar vergleichsweise stark auf C++ oberhalb des Kernels, ich glaube HP-UX auch, da bin ich mir aber nicht so sicher. Objective-C nehmen die (und empfehlen natürlich) hauptsächlich für Anwendungsprogramme.

*john 0

Für die Treiberentwicklung wird bei MacOS X ein abgespecktes C++ verwendet. Objective-C wird für das Cocoa Framework und die darauf aufbauenden Applikationen benutzt.

Danke erstmal an alle!

@Tntnet: Genau solche Erfahrungen wollte ich gerne hören. Unabhängig von diesem Thread, hast Du mal Benchmarks gemacht wie sich Dein Web-Framework im Vergleich mit FastCGI skaliert?

@rüdiger:
Du meinst die dietlibc erweitern, damit sich die libstdc++ gegen die dietlibc linken lässt?

@Topic:
In den verlinkten Dokumenten ist mehrmals die Rede davon, dass mehr Code zu Cache Misses führen kann. Soweit klar, aber in wie weit ist C++ davon betroffen, habt ihr interessante Bookmarks/Literatur zu dem Thema?

Shade Of Mine

~john schrieb:

Für all diese Probleme gibt es Lösungen, bzw. sie sind aus Sicht aus höheren Programmiersprachen geschrieben.

Und das lustige - man kann mit board Mitteln von C++ ja die Abstraktion fast unendlich nach oben schrauben, je nachdem ob man will oder nicht.

Dann sind solche bescheuerten argumente wie "no high-level builtin types" oder "no runtime encapsulation". Das einzige was an dieser liste stimmt ist: komplizierte grammatik (was aber andere auswirkungen hat als der autor sich ausgedacht hat) und keine reflection.

warum sehen die Leute nicht die echten Probleme von C++?

zu langsamerer standardisierungsprozess (und daher zuviele dialekte), zuviele insel loesungen bei libraries und die guten libraries sind alt und daher nicht in modernen c++ geschrieben, zu schwache development tools (wegen komplizierter grammatik) und keine standardisierte ABI.

das sind die wirklichen probleme. stattdessen liest man immer wieder "komplizierte grammatik", "keine reflection", "boeses operator overloading",...

rüdiger

btw. ein schönes Beispiel für schlankeres und schnelleres C++-Programm vs fetteres und langsameres C-Programm ist wohl KDE vs GNOME.

Mustermann schrieb:

@rüdiger:
Du meinst die dietlibc erweitern, damit sich die libstdc++ gegen die dietlibc linken lässt?

Eher damit man C++-Programme mit der dietlibc linken kann.

Shade Of Mine schrieb:

warum sehen die Leute nicht die echten Probleme von C++?

zu langsamerer standardisierungsprozess (und daher zuviele dialekte), zuviele insel loesungen bei libraries und die guten libraries sind alt und daher nicht in modernen c++ geschrieben, zu schwache development tools (wegen komplizierter grammatik) und keine standardisierte ABI.

Shade Of Mine

rüdiger schrieb:

was sind deiner meinung nach dann die probleme von c++?

imho sind die ganzen dialekte die jeder compiler mitbringt ein problem da es schwer ist standardisierte tools dadrauf zu setzen. und die portabilitaet ist ja quasi nur mit dem gleichen compiler gegeben da viele systemabhaengige sachen wie zB calling conventions oder padding bytes oder sonstige attribute von jedem compiler syntaktisch anders geloest werden.

die komplexe grammatik verhindert dass man viele gute tools hat die mit c++ code umgehen koennen. refactoring, etc. visual studio ist zwar ziemlich gut, aber jede x-beliebige freie java ide hat die selben features und meistens noch etwas mehr gratis dabei, weil der aufwand der implementierung soviel geringer ist.

die inselloesungen bei libraries bindet mich an bestimmte firmen. wenn ich zB cross plattform anwendungen entwickeln will kann ich zwischen wxWidgets, Qt und gtkmm entscheiden - diese 3 bieten mir eine vernuenftige plattform. dabei fallen gtkmm und wxWidgets wegen windows respektive mac os weg, da sie dort nicht gut genug laufen. haben wir Qt oder uU auch eine andere Insel -> keine standardisierten tools dafuer. bei java habe ich standardisierte libraries was code generation enorm vereinfacht und ich kann problemlos die plattform wechseln und bin nicht an Sun gebunden da ich eine andere jvm nehmen kann.

und dass eine standardisierte abi fehlt ist halt furchtbar wenn es um interop geht. man muss hoellisch mit den compilern aufpassen dass man wirklich immer eine kompatible abi hat. das erschwert es mit dlls/shared objects zu arbeiten und das ist aergerlich.