Der Nachfolger von ANSI C
-
Steht der schon fest ?
MfG
Hansi D.
-
Naja, was meinst du mit ANSI C?
Aktuell: ISO/IEC 9899:1999 (C99)
Vorher: ISO/IEC 9899:1990 (C90)Von einer Revision wüsst ich bis jetzt nix.
greetz, Swordfish
-
Habe von ein paar unschlüssigen Überlegungen gehört. Gab wohl einige Vorschläge, zB für Fixnum-Arithmetik.
(Bisher verschmähen die meisten Compiler ja sogar noch den größten Teil der C99 Feature
)
btw. gibt es zu C99 ein TC2 von 2004 http://www.open-std.org/jtc1/sc22/wg14/www/docs/9899-1999_cor_2-2004.pdf
-
Es wird niemals einen Nachfolger von ANSI C geben.
C++ und JAVA sind nur Hochsprachen, die für jene Programmierer erfunden wurden, die Angst vor den Zeigern und der Speicherverwaltung haben.
Programmierer, die Angst vor den Zeigern/Speicherverwaltung haben, sind eigentlich Anwender. Das kreative Element beim Programmieren geht total verloren.
IMO
-
C-Fan6x10hoch9 schrieb:
Programmierer, die Angst vor den Zeigern/Speicherverwaltung haben, sind eigentlich Anwender. Das kreative Element beim Programmieren geht total verloren.
IMO
boehm GC ftw!
-
c.rackwitz schrieb:
boehm GC ftw!
So und jetzt bitte einmal auf deutsch
-
-
http://www.open-std.org/JTC1/SC22/WG14/
Da kann man nachlesen worüber so diskutiert wird. Fixpunkt-Arithmetik würde mir sehr gefallen und ist für die Anwendungsgebiete von C auch wichtig imho.
-
ist nicht D der nachfolger von C?
c.rackwitz schrieb:
boehm GC ftw!
das ist doch schummel. ein GC funzt doch nur richtig in virtual machines.
-
C wird noch selber weiterentwickelt (die letzte Version ist afaik C99), parallel gab es als größere Erweiterungen (im Prinzip könnte man es als Nachfolger ansehen) ObjectiveC und C++ (und aus letzterem hat sich dann Java, C# und irgendwann D entwickelt).
-
pale dog schrieb:
ist nicht D der nachfolger von C?
c.rackwitz schrieb:
boehm GC ftw!
das ist doch schummel. ein GC funzt doch nur richtig in virtual machines.
was ist da schummel? es ist ein GC. er hat nicht ganz das wissen ueber den speicher den ein GC in einer virtuellen maschine hat, aber er sammelt den muell dennoch zuverlaessig auf.
wenn das schummeln ist, dann sind referenzen nur geschummelte zeiger und integer nur geschummelte fliesskommazahlen.
-
Shade Of Mine schrieb:
pale dog schrieb:
ist nicht D der nachfolger von C?
c.rackwitz schrieb:
boehm GC ftw!
das ist doch schummel. ein GC funzt doch nur richtig in virtual machines.
was ist da schummel? es ist ein GC. er hat nicht ganz das wissen ueber den speicher den ein GC in einer virtuellen maschine hat, aber er sammelt den muell dennoch zuverlaessig auf.
okay, schummel klingt nach 'das darf man nicht', aber so war's natürlich gemeint
ich meinte mehr, dass diese methode, mit einer hintergrundtask den speicher nach pointern zu durchsuchen ein ziemlich mieser hack ist. es gibt bestimmt fälle, in denen das nicht funktioniert. ausserdem muss die laufzeitumgebung threads/tasks anbieten, damit der GC arbeiten kann, das macht ihn schon mal unbrauchbar für umgebungen, in denen das nicht so ist. ich finde z.b. sowas besser:create_heap(); // // hier einige malloc() und free()'s // destroy_heap();
danach ist garantiert alles aufgeräumt, auch wenn im code dazwischen irgendwo ein paar 'frees' fehlen...
-
pale dog schrieb:
ich meinte mehr, dass diese methode, mit einer hintergrundtask den speicher nach pointern zu durchsuchen ein ziemlich mieser hack ist. es gibt bestimmt fälle, in denen das nicht funktioniert. ausserdem muss die laufzeitumgebung threads/tasks anbieten, damit der GC arbeiten kann, das macht ihn schon mal unbrauchbar für umgebungen, in denen das nicht so ist.
Und dort laeuft dann eine Java VM mit 100% Leistung?
ich finde z.b. sowas besser:
create_heap(); // // hier einige malloc() und free()'s // destroy_heap();
danach ist garantiert alles aufgeräumt, auch wenn im code dazwischen irgendwo ein paar 'frees' fehlen...
[/quote]
kann der boehm gc problemlos, bis auf dass du dir das destroy_heap sparst :p man muss nicht immer rumsuchen...
-
@pale dog
Nee, man braucht keine VM man muss nur wissen was Pointer sind und worauf die zeigen. Für letzteres hat C99 mit strikt-aliasing ja schon einiges getan. Wenn man einen modernen GC will, braucht man wohl aber ein wenig Compiler-Support.Das GCs wunderbar ohne VM funktionieren zeigt ja zB Lisp und das seit den 50ern
:p
-
ein GC braucht auch keine "hintergrund-tasks".
die gc_ funktionen werden periodisch bei gc_malloc() aufgerufen.
ein hack ist das auch nicht, denn es gibt eigentlich nur 2 hauptarten von GCs:
mark and sweep (und mark and move, siehe wiki seiten)
refcountingwobei refcounting tueckisch ist: zyklen zu erkennen braucht nochmal logik.
-
rüdiger schrieb:
Wenn man einen modernen GC will, braucht man wohl aber ein wenig Compiler-Support.
das denke ich auch. einen GC nachträglich dranzustöpseln kann sehr problematisch sein. was ist z.b. wenn der code den pointer in einem register hält, während der GC den speicher absucht, den pointer nicht findet und den heap-block freigibt?
c.rackwitz schrieb:
ein GC braucht auch keine "hintergrund-tasks".
die gc_ funktionen werden periodisch bei gc_malloc() aufgerufen.dann wird das letzte 'gc_malloc()' aber nie freigegeben
-
pale dog schrieb:
dann wird das letzte 'gc_malloc()' aber nie freigegeben
atexit
-
Shade Of Mine schrieb:
pale dog schrieb:
dann wird das letzte 'gc_malloc()' aber nie freigegeben
atexit
dann ist's ja egal. moderne betriebssysteme geben den speicher sowieso beim beenden eines prozesses frei.
aber mal ehrlich, C wird doch heutzutage kaum noch auf grossen systemen eingesetzt (ausser im kernel). da nimmt man C#.NET, Java, oder irgendwelche interpretierten scriptsprachen wie phyton usw., die sowieso ihre eigene müllbeseitigung haben. welchen sinn macht ein GC für eine low-level sprache wie C, die meistens in umgebungen eingesetzt wird, in denen oft noch nicht mal malloc/free verwendet werden können?
-
-
Shade Of Mine schrieb:
okay, die haben also ihre software in C geschrieben, dann festgestellt, dass sie garbage collection benötigen und den böhm-GC eingesetzt.
wenn ich gemein wäre, würde ich denen sagen: 'ihr wusstet doch vorher, dass eure programme für standard-pc's u.ä. workstations konzipiert sind. warum nehmt ihr dann C und nicht Java oder etwas vergleichbares, das für diese umgebungen besser geeignet ist?'