Schlanke Programme mit C++
-
fricky schrieb:
muemmel schrieb:
C++ wurde entwickelt um damit Großprogramme wie Betriebssysteme und Compiler für PCs mit Speicher im Gigabyte-Bereich effektiv und effizient schreiben zu können.
seltsamerweise baut kaum einer betriebssysteme in c++. die bekanntesten pc-os'se sind jedenfalls nicht in c++ programmiert worden.
hallo du schlaumeier, schon mal was von
Windows XP
Windows NT (NT4 and 2000)
Windows 9x (95, 98, Me)
gehört?
-
Naja, der Kernel-Code ist wohl schon C. Wie die unixoiden Systeme. Im Gegensatz zu den BSDs und Linux wird bei Microsoft im Userland allerdings wesentlich mehr auf C++ gesetzt, gerade auch durch die graphischen Administrationstools, z.B. in der Systemsteuerung, die bspw. die MFC verwenden.
-
kreater@woanders schrieb:
hallo du schlaumeier, schon mal was von
Windows XP
Windows NT (NT4 and 2000)
Windows 9x (95, 98, Me)
gehört?ja, siehe beitrag von Xantus. es stimmt, was er sagt.
-
fricky schrieb:
kreater@woanders schrieb:
hallo du schlaumeier, schon mal was von
Windows XP
Windows NT (NT4 and 2000)
Windows 9x (95, 98, Me)
gehört?ja, siehe beitrag von Xantus. es stimmt, was er sagt.
Warum musst du immer alles besser wissen? 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.
-
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.
-
Neugieriger schrieb:
Warum musst du immer alles besser wissen?
weil ich die geleakten win2k-codes irgendwo noch rumfliegen habe und in gewissen büchen von m$ (inside windows nt/2000, etc.) steht das, glaube ich, auch drin. die kernkomponenten, also alles unterhalb der 'executive api', sind definitiv nicht in c++ programmiert worden. nur relativ unwichtige usermode-programme, ohne die das system auch laufen kann (aber vielleicht nicht so gut bedienbar wäre) sind in c++ gecodet worden.
-
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.
-
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.
-
sri schrieb:
Variablendeklaration auch mitten in der Funktion bzw. im Block
das bitte aus der liste rausstreichen
-
sothis_ schrieb:
sri schrieb:
Variablendeklaration auch mitten in der Funktion bzw. im Block
das bitte aus der liste rausstreichen
Warum?
-
Tachyon schrieb:
Warum?
weil das seit C99 der vergangenheit angehört.
-
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.
-
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.
-
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...
-
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.
-
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.
-
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.
