D
-
volkard schrieb:
knivil schrieb:
Und spaetestens jetzt ist es ein Thread im Sinne von C++ vs. rest of the world.
Es ist wieder ein von fricky entführter C++-Bashing-Thread. Wie Du gerne nachlesen wirst, hat wiedermal fricky angefangen damit.
Ich hatte eher den Eindruck, dass *du* der erste warst, der überhaupt mit Programmiersprache-Bashing anfing. Siehe deinen ersten Post
Naja, C ist inzwischen bloß noch lächerlich.
asc schrieb:
;fricky schrieb:
es gibt nun mal bereiche, in denen C die nase ganz kar vorn hat.
Deine Scheuklappen solltest du vielleicht mal ablegen (und dich fragen warum viele Firmen nicht in C Programmieren sondern beispielsweise auch aus guten Gründen in dem "ach so schlechten" C++ oder anderen Sprachen)...
das gleiche kann man euch auch sagen. Es gibt auch viele Firmen, die C verwenden, meine z.B. Wir verwenden nicht ausschließlich C, aber für die hardware nahe Geschichten schon.
-
supertux schrieb:
asc schrieb:
Deine Scheuklappen solltest du vielleicht mal ablegen (und dich fragen warum viele Firmen nicht in C Programmieren sondern beispielsweise auch aus guten Gründen in dem "ach so schlechten" C++ oder anderen Sprachen)...
das gleiche kann man euch auch sagen. Es gibt auch viele Firmen, die C verwenden, meine z.B. Wir verwenden nicht ausschließlich C, aber für die hardware nahe Geschichten schon.
Wo habe ich bitte Scheuklappen aufgesetzt. Den auch wenn ich persönlich mit C nur wenig am Hut habe, habe ich C niemals die Existensberechtigung oder den Sinn abgesprochen. Selbiges macht fricky aber ständig sofern es nicht um C geht.
Ich kenne einige Firmen die in C programmieren (vorwiegend im Embedded, oder allgemein Hardwarenahen bereich), aber in meinen Bereich (Unternehmensanwendung) kenne ich keine einzige mehr die C verwendet (sofern es nicht um die pflege sehr alter Projekte geht). Wohl nahezu jede Sprache hat Stärken - und einer Sprache mit soviel Marktanteil wie beispielsweise von C, C++, C#, Java, PHP & Co die Existenzberechtigung abzusprechen ist einfach nur blind.
-
asc schrieb:
Wohl nahezu jede Sprache hat Stärken - und einer Sprache mit soviel Marktanteil wie beispielsweise von C, C++, C#, Java, PHP & Co die Existenzberechtigung abzusprechen ist einfach nur blind.
das stimmt doch überhaupt nicht. C, C#, PHP und Java hab' ich noch nie die existenzberechtigung abgesprochen.
-
soviel zu D.
was ist mit E?
-
E+ schrieb:
soviel zu D.
was ist mit E?finger weg, das macht dich recht schnell kaputt!
-
mal wieder toll 
-
naja der war ja aufgelegt
-
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.
