D
-
;fricky schrieb:
naja, aber hier steht
Und C kann also auch keine unterschiedlichen modelle weil man ja nur malloc/calloc/realloc hat um speicher zu reservieren...
-
Shade Of Mine schrieb:
Und C kann also auch keine unterschiedlichen modelle weil man ja nur malloc/calloc/realloc hat um speicher zu reservieren...
^^ in OS-kernels gibts spezielle funktionen dafür, wie 'kmalloc' (unter linux) bzw. 'ExAllocatePool' (unter windows) und einiges mehr. das arbeiten mit verschiedenen speicherbereichen ist immer systemabhängig, aber in C eigentlich niemals problematisch.
-
;fricky schrieb:
naja, aber hier steht: ( http://www.sgi.com/tech/stl/Allocators.html )
Das trifft so wie es da steht auch auf C zu, da muß die Differenz zwischen zwei Pointern auch immer ein ptrdiff_t sein. Nachzulesen in ISO C §6.5.6 Absatz 9. Trotzdem hintern das niemanden daran Kernel mit C zu programmieren.
-
Ein Speichermodell, welches man in C abbilden kann, aber nicht in einem STL-Allokator?
Kann mir mal jemand ein Beispiel geben?
Zum Thema:
D hat immer versucht, ein verbessertes C++ zu sein. Das Problem ist: was heisst das? Das aktuelle Resultat (ich meine damit das sich in Arbeit befindliche D 2.0) hat in der Tat coole Features, u.a. für Metaprogrammierung und generische Programmierung. Für mich hat es aber folgende Showstopper:
- Kein Argument Dependent Lookup (oder ähnliches). Dadurch ist generischer Code viel schwerer zu schreiben. In C++ müssen dank ADL nicht alle Funktionsaufrufe in Template-Code im selben Namespace wie das Template selbst vorkommen. Wenn der Compiler die Funktion nicht in diesem Namespace findet, schaut es sich die Argumente an, und schaut in deren Namespaces nach. D hat sowas nicht -> alle Aufrufe müssen im selben Namespace wie der Template-Code sein.
- Namespaces nicht frei wählbar, sondern fix mit der Verzeichnisstruktur verdrahtet. "import foo.abc.def" erzwingt das Layout "foo/abc/def.d". Für mich persönlich sehr störend, VOR ALLEM wegen dem ADL-Problem oben.
- Kaputtes Operatorüberladen. Mein Lieblingsbeispiel da ist der Ausdruck v[5] = 7; In D ist []= ein Operator; [] existiert nur als RHS-Variante, nicht als LHS-Version. In C++ ist die LHS-Version "type & operator [](index)". Ein []= Operator verzahnt Zugriff und Zuweisung. Vor allem für Container ist das sehr schlecht.
- Wenig Verbreitung & Libraries. Das ist kein Problem in der Sprache selbst, aber trotzdem relevant.
- Generelles Fehlen eines Fokus. C++ fokussiert sich jetzt sehr stark auf generisches Programmieren, D folgt dem, was grad "cool" ist. Dabei hätten sie - mit einigen Designverbesserungen, siehe oben - die Chance, gerade in diesem Gebiet zu punkten. Stattdessen nutzen nur wenige die Sprache dahingehend aus.
Somit kommt in Summe nix heraus, was es zu einem C++-Killer macht..
-
~john schrieb:
;fricky schrieb:
naja, aber hier steht: ( http://www.sgi.com/tech/stl/Allocators.html )
Das trifft so wie es da steht auch auf C zu, da muß die Differenz zwischen zwei Pointern auch immer ein ptrdiff_t sein. Nachzulesen in ISO C §6.5.6 Absatz 9. Trotzdem hintern das niemanden daran Kernel mit C zu programmieren.
C ist aber nicht auf diese seltsamen allokatoren angewiesen, die STL scheinbar schon. wenn man also in 'nem kernel c++ und STL verwenden will, bräucht man verschiedene allokatoren für die verschiedenen speicherbereiche und müsste dem jeweiligen STL-objekt einen passenden allokator mitgeben. bekommt man bestimmt irgendwie hin, ist halt bastelei (und unnötig kompliziert, wobei überschüssige komplexität in C++ ja nichts ungewöhnliches ist *fg*). es gibt ja auch in C++ geschriebene experimentelle kernels, also gehen tut das schon irgendwie, die frage ist nur, ob es sinnvoll ist.
Ein Speichermodell, welches man in C abbilden kann, aber nicht in einem STL-Allokator?
Kann mir mal jemand ein Beispiel geben?z.b. diese funktionen hier: http://msdn.microsoft.com/en-us/library/ms796689.aspx
müsste man irgendwie in STL-allokatoren benutzen (und in new/delete/delete[] wohl auch), wenn man c++ und STL im win-kernel benutzen wollte.
-
Wer sagt denn, daß ich für einen Kernel die Standardlib überhaupt nehmen würde? C++ ist nicht nur eine Bibliothek. Die mag ich sogar gar nicht so. C++ ist eine supi Sprache.
-
Sowohl C als auch C++ sind gute Sprachen. Ich benutze beide regelmäßig. In C schätze ich das ich den vollen Überblick habe (Die Bibliothek mir keine Aufgaben abnimmt). In C++ jedoch kann man komplizierte Programme viel besser strukturieren, und die Datenverwaltung ist flexibler.
-
volkard schrieb:
C++ ist eine supi Sprache.
ansichtssache, jedenfalls nicht für kernelmodule. c++ ist im linux-kernel sowieso ein grosses no-no! und unter windows: http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx
(lies ab: C++ Issues for Kernel-Mode Drivers)
zusammenfassend kann man sagen: C++ im kernel zu nutzen ist nicht unmöglich, aber sehr fehlerträchtig, so dass man besser die finger davon lassen sollte.In C++ jedoch kann man komplizierte Programme viel besser strukturieren
hihi, vielleicht wären die programme garnicht erst kompliziert, wenn du was anderes als C++ benutzt hättest.
-
nein für Kernel sollte man C++ nicht benutzen. Das gillt aber glaub ich bei allen OOP Sprachen genauso.
hihi, vielleicht wären die programme garnicht erst kompliziert, wenn du was anderes als C++ benutzt hättest.
War das ein Witz oder Sarkasmus?
-
C ist die beste Sprache von der Welt!
-
player4245 schrieb:
hihi, vielleicht wären die programme garnicht erst kompliziert, wenn du was anderes als C++ benutzt hättest.
War das ein Witz oder Sarkasmus?
mindestens sarkasmus.
-
E+ schrieb:
soviel zu D.
was ist mit E?E ... RROR ?
nein danke
-
;fricky schrieb:
player4245 schrieb:
hihi, vielleicht wären die programme garnicht erst kompliziert, wenn du was anderes als C++ benutzt hättest.
War das ein Witz oder Sarkasmus?
mindestens sarkasmus.
unwissenheit gepaart mit dummheit
gute kombination
-
damit war ich aber hoffentlich nicht gemeint?
-
player4245 schrieb:
damit war ich aber hoffentlich nicht gemeint?
Nein, die Beschreibung trifft eher auf fricky zu.
Vielleicht kennst du fricky noch zu wenig, um zu erkennen, dass er ein fundamentalistischer Troll ist, der C++ über alles hasst, sämtliche Argumente ignoriert und Freude daran hat, andere mit seinem Geschwafel zu nerven.
-
naja ich hatte seine beiträge bis vor einem monat noch als relativ gut eingeschätzt. Aber nun zankt er sich ja reglmäßig mit volkard.
-
@player4245:
nö, das war nicht an dich gerichtet.
-
!!! schrieb:
fricky ...der C++ über alles hasst.
das stimmt.
!!! schrieb:
... sämtliche Argumente ignoriert ...
es gibt keine rationalen argumente pro C++. ob's einer mag oder nicht ist reine glaubenssache.
player4245 schrieb:
Aber nun zankt er sich ja reglmäßig mit volkard.
ich zanke mich nicht mit volkard. volkard ist in letzter zeit ein wenig durch den wind, aber eigentlich ist er ein netter kerl.
-
;fricky schrieb:
C ist aber nicht auf diese seltsamen allokatoren angewiesen, die STL scheinbar schon. wenn man also in 'nem kernel c++ und STL verwenden will, bräucht man verschiedene allokatoren für die verschiedenen speicherbereiche und müsste dem jeweiligen STL-objekt einen passenden allokator mitgeben.
Da man die Allokatoren nur einmal schreiben muß, wäre das kein nennenswerter Mehraufwand. Die Allokatoren sind eine explizite Schnittstelle für die Speicheranforderung von Containerklassen, die man bei eigenen Klassen ebenfalls nutzen kann.
;fricky schrieb:
die frage ist nur, ob es sinnvoll ist.
Ist es, da der Wartungswaufwand für den Code geringer wird.
-
player4245 schrieb:
nein für Kernel sollte man C++ nicht benutzen. Das gillt aber glaub ich bei allen OOP Sprachen genauso.
Es wurden Betriebssysteme schon in ganz anderen Sprachen geschrieben. C++ ist nur eine davon. Gewiss kann man nicht auf Assembler oder C z.B. bei der Initialisierung verzichten, aber alles andere kann in einer beliebigen Sprache erfolgen. Es gab Betriebssysteme in Lisp, es gibt welche in C++ und sogar in C#. Aktuell gibt es fuer den Linuxkernel sogar Module, die Scheme oder Haskell im Kernelmodus interpretieren (inkulsive den Features wie garbage collection). Und nein, es ist kein Hack. Und wer von Aufwand redet, sollte erstmal ein Betriebssystem in C schreiben, denn aufwendig ist alles.
