Am Fri, 31 Oct 2014 06:44:48 +0200 schrieb ketmar via Digitalmars-d <[email protected]>:
> On Fri, 31 Oct 2014 05:38:48 +0100 > Marco Leise via Digitalmars-d <[email protected]> wrote: > > > GtkD wraps all the objects in Gtk. In callbacks like "onDraw", > > when they are called often, this creates heaps of tiny wrapper > > objects around huge data from C libraries. Eventually system > > memory is exhausted and the computer slows down and eats into > > swap. So should we add a "run garbage collector" button to > > every application to clean those up? Seems rather silly. > > > > The GC should stick to its own memory and not try to manage > > resources it doesn't understand. Reference counting applies to > > external and system resources much better. To date neither the > > language nor Phobos can ref count classes. And even with > > library support it is not likely that it will get used widely, > > because plain classes are so much easier (also on the eyes). > > > > The extent of this is pretty huge. There are many D wrapper > > libraries that build on classes and mimic what is available > > for C++ or Python. Issues like this make D appear like a toy > > language. How would one write a big desktop application when > > a simple animation can exhaust system memory in seconds ? > why do you blaming GC for what seems to be a library author's fault? > that was the library author who chooses to wrap externally-managed > objects in GC objects, and creating alot of throwaway classes for that. Can't blame the author when there is no other choice in the language than to use tracing GC with inheritance. > alas, we haven't Skynet at the hand to guess what author really wants. > > p.s. i was never using GtkD, so i don't know if it's really doing the > things you wrote or not, i'm just assuming that you are right. To be fair there is an overload for addOnDraw that takes a delegate that has a Scoped!Context as parameter, but I cannot use that with delegates marked as nothrow since Scoped's dtor isn't nothrow. Which prompts the question again how to deal with exceptions in dtors. All D delegates called from the C side have to be nothrow though, because neither can druntime deal with GCC's amd64 stack (omit-frame-pointer) nor is the C side necessarily prepared for exceptions. -- Marco
