Der Nachfolger von ANSI C

pale dog

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.

CStoll

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).

Shade Of Mine

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.

pale dog

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...

Shade Of Mine

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...

rüdiger

@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

c.rackwitz

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)
refcounting

wobei refcounting tueckisch ist: zyklen zu erkennen braucht nochmal logik.

pale dog

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

Shade Of Mine

pale dog schrieb:

dann wird das letzte 'gc_malloc()' aber nie freigegeben

atexit

pale dog

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

schau dir doch einfach mal die seite an

pale dog

Shade Of Mine schrieb:

schau dir doch einfach mal die seite an

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?'

Shade Of Mine

pale dog schrieb:

Shade Of Mine schrieb:

schau dir doch einfach mal die seite an

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?'

objective-c compiler? ja, definitiv bullshit sowas in C zu schreiben. eine virtual machine fuer .net programme - ja klar, bullshit sowas in c zu schreiben...

sorry.

aber wenn du dir die liste anschauen wuerdest, wuerdest du sehen dass es sehr spezielle anforderungen sind. meistens eben virtual machines oder aehnliches. kaum jemand wird ne normale anwendung in C mit GC schreiben. aber was man halt bedenken sollte ist, dass ein GC mehr ist als nur free() sparen. er uebernimmt das komplette memory management, was zB deutlich schnellere allocs bedeutet.

aber ok, beenden wir die diskussion: der boehm gc ist bullshit und jeder der den verwendet der nuckelt...

pale dog

Shade Of Mine schrieb:

objective-c compiler? ja, definitiv bullshit sowas in C zu schreiben. eine virtual machine fuer .net programme - ja klar, bullshit sowas in c zu schreiben...

warum?

Shade Of Mine schrieb:

...aber was man halt bedenken sollte ist, dass ein GC mehr ist als nur free() sparen. er uebernimmt das komplette memory management, was zB deutlich schnellere allocs bedeutet.

sicher, wobei ich im böhm-GC FAQ mal gelesen habe, dass das allozieren nun wirklich recht langsam sein soll, übrigens im krassen gegensatz zum .NET GC, der rasend schnell arbeitet, allerdings nach einem völlig anderen prinzip als der böhm-GC. (übrigens kein wunder, falls der böhm-GC keine background task zum aufräumen verwendet).

Shade Of Mine schrieb:

der boehm gc ist bullshit und jeder der den verwendet der nuckelt...

naja, in grenzfällen mag der einsatz eines GC für C durchaus berechtigt sein, aber die sind bestimmt selten. ich z.b. programmiere viel in C aber ich glaube nicht, dass ich dabei jemals einen GC verwenden würde, allein schon wegen des indeterministischen zeitverhaltens, denn dort, wo man in C programmiert, (und das ist nun mal hardwarenah, microcontroller, kernel) spielt sowas oft eine wichtige rolle und da stört ein GC mehr, als dass er was nützen würde...

Shade Of Mine

pale dog schrieb:

sicher, wobei ich im böhm-GC FAQ mal gelesen habe, dass das allozieren nun wirklich recht langsam sein soll, übrigens im krassen gegensatz zum .NET GC, der rasend schnell arbeitet, allerdings nach einem völlig anderen prinzip als der böhm-GC. (übrigens kein wunder, falls der böhm-GC keine background task zum aufräumen verwendet).

Performance of the nonincremental collector is typically competitive with malloc/free implementations. Both space and time overhead are likely to be only slightly higher for programs written for malloc/free (see Detlefs, Dosser and Zorn's Memory Allocation Costs in Large C and C++ Programs.) For programs allocating primarily very small objects, the collector may be faster; for programs allocating primarily large objects it will be slower. If the collector is used in a multithreaded environment and configured for thread-local allocation, it may in some cases significantly outperform malloc/free allocation in time.

naja, in grenzfällen mag der einsatz eines GC für C durchaus berechtigt sein, aber die sind bestimmt selten.

habe ich je etwas anderes behauptet? ich habe es sogar explizit gesagt dass es nicht fuer alle anwendungen sinnvoll ist.

ich z.b. programmiere viel in C aber ich glaube nicht, dass ich dabei jemals einen GC verwenden würde, allein schon wegen des indeterministischen zeitverhaltens, denn dort, wo man in C programmiert, (und das ist nun mal hardwarenah, microcontroller, kernel) spielt sowas oft eine wichtige rolle und da stört ein GC mehr, als dass er was nützen würde...

themenverfehlung. es geht hier nicht um microkontroller...

aber wie ich gesagt habe: jeder der den boehm gc oder generell einen gc verwendet, der nuckelt derbe. dass es situationen gibt wo ein gc einfach verdammt praktisch ist, die lassen wir einfach aussen vor. wir nennen einfach nur alle situationen wo ein gc unpraktisch ist und beweisen damit, dass ein gc bullshit ist.

pale dog

Shade Of Mine schrieb:

wir nennen einfach nur alle situationen wo ein gc unpraktisch ist und beweisen damit, dass ein gc bullshit ist.

nein, wir versuchen einfach zu beweisen, dass ein GC für C unpraktisch ist, weil die domäne von C eine gänzlich andere ist, als die, in denen für gewöhnlich andere sprachen verwendet werden, bei denen garbage collection ein selbstverständlich eingebautes feature ist...

proggingmania

Shade Of Mine schrieb:

aber ok, beenden wir die diskussion: der boehm gc ist bullshit und jeder der den verwendet der nuckelt...

LOL

c.rackwitz

pale dog schrieb:

Shade Of Mine schrieb:

wir nennen einfach nur alle situationen wo ein gc unpraktisch ist und beweisen damit, dass ein gc bullshit ist.

nein, wir versuchen einfach zu beweisen, dass ein GC für C unpraktisch ist, weil die domäne von C eine gänzlich andere ist, als die, in denen für gewöhnlich andere sprachen verwendet werden, bei denen garbage collection ein selbstverständlich eingebautes feature ist...

du willst nicht ueber dich hinaus wachsen. das ist OK.

dass du den sinn hinter dem boehm GC nicht begreifst ist auch OK.

aber dann tu nicht so als ob du wuesstest, wovon du redest.

pale dog

c.rackwitz schrieb:

du willst nicht ueber dich hinaus wachsen. das ist OK.

wie meinst du das?

c.rackwitz schrieb:

aber dann tu nicht so als ob du wuesstest, wovon du redest.

tu ich doch gar nicht. ich erzähle hier nur meine meinung. wenn du einen GC in deinen C programmen benutzen willst, dann kannst du das tun. hab' ich nix dagegen...

Wir wenden uns jetzt wieder dem Thema zu.