D
-
On Topic:
D ist hauptsächlich anders, aber nicht wirklich besser. Es gibt einige nette Features, die aber kaum den Umstieg rechtfertigen. Zumal C++ Programme keine gültigen D Programme sind.Off Topic
;fricky schrieb:
c++ macht zu vieles automatisch. …
fricky beweist mal wieder, daß er von C++ keinerlei Ahnung hat.
Angesichts der Tatsache, daß nur ganz wenige C Programme keine gültigen C++ Programme sind bzw. in diese überführt werden (void* cast) können, ist das mal wieder ein Glanzleistung von Dir.
-
~john schrieb:
Angesichts der Tatsache, daß nur ganz wenige C Programme keine gültigen C++ Programme sind bzw. in diese überführt werden (void* cast) können, ist das mal wieder ein Glanzleistung von Dir.
es ging um gewöhnliches c++, nicht 'wir benutzen c++ wie C'. unter anderem wurde STL erwähnt. ausserdem ist die liste der unverträglichkeiten von C und C++ ziemlich lang. du würdest dich wundern.
-
die is tiny
-
;fricky schrieb:
… unter anderem wurde STL erwähnt.…
Gerade die STL ist sehr viel flexibler als Dir das bekannt ist. Deine Verweise auf angebliche Inkompatibilität der STL mit besonders angeforderten Speicherbereichen ist nicht zutreffend.
-
~john schrieb:
Gerade die STL ist sehr viel flexibler als Dir das bekannt ist. Deine Verweise auf angebliche Inkompatibilität der STL mit besonders angeforderten Speicherbereichen ist nicht zutreffend.
klar, eine anpassung sollte gehen, die STL liegt ja schliesslich im quellcode vor. es gibt sogar delphi-fans die kernelmodule in delphi geschrieben haben. also, dass derartige basteleien völlig unmöglich sind, kann man wohl ausschliessen. bleibt nur die frage, wie alltagstauglich das ganze wird. selbst unter normalen bedingungen ist c++ ja schon ein ziemlich widerspenstiges etwas.
-
;fricky schrieb:
~john schrieb:
Gerade die STL ist sehr viel flexibler als Dir das bekannt ist. Deine Verweise auf angebliche Inkompatibilität der STL mit besonders angeforderten Speicherbereichen ist nicht zutreffend.
klar, eine anpassung sollte gehen, die STL liegt ja schliesslich im quellcode vor. es gibt sogar delphi-fans die kernelmodule in delphi geschrieben haben. also, dass derartige basteleien völlig unmöglich sind, kann man wohl ausschliessen. bleibt nur die frage, wie alltagstauglich das ganze wird. selbst unter normalen bedingungen ist c++ ja schon ein ziemlich widerspenstiges etwas.
du musst keine zeile Code umschreiben.
-
;fricky schrieb:
klar, eine anpassung sollte gehen, die STL liegt ja schliesslich im quellcode vor.
Das einzige was man tun muß, ist eigene Allokatoren zu verwenden, denn die STL Container sind darauf explizit ausgelegt.
-
~john schrieb:
Das einzige was man tun muß, ist eigene Allokatoren zu verwenden, denn die STL Container sind darauf explizit ausgelegt.
naja, aber hier steht: ( http://www.sgi.com/tech/stl/Allocators.html )
Note also that allocators do not attempt to encapsulate multiple memory models. The C++ language only defines a single memory model (the difference of two pointers, for example, is always ptrdiff_t), and this memory model is the only one that allocators support.
-
;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
