Der Nachfolger von ANSI C
-
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?'
-
pale dog schrieb:
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?'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...
-
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...
-
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.
-
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...
-
Shade Of Mine schrieb:
aber ok, beenden wir die diskussion: der boehm gc ist bullshit und jeder der den verwendet der nuckelt...
LOL
-
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.
-
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.
-
D ist genauso wenig der nachfolger von C wie C++ oder java es ist.
-
c.rackwitz schrieb:
D ist genauso wenig der nachfolger von C wie C++ oder java es ist.
was könnte es denn deiner meinung nach sein?
-
pale dog schrieb:
c.rackwitz schrieb:
D ist genauso wenig der nachfolger von C wie C++ oder java es ist.
was könnte es denn deiner meinung nach sein?
naechste revision des C standards.