On Wed, Feb 9, 2011 at 4:44 PM, Tor Lillqvist <t...@iki.fi> wrote: > It's just a question of definition. Many people, me included, don't > consider once-only allocations of memory that stays accessible and > aren't freed before the program exits leaks. GTK+ and GLib isn't the > kind of libraries that you could load dynamically, use a bit, and then > unload, and expect to free all their allocations upon unloading. >
IMO there is a use-case for this (or at least a gtk_fini ();) especially in applications where the UI elements are controlled by loadable modules. Not unloading like this is extremely dangerous when those allocated objects and slots go stale and the application might try to re-load the module which initializes gtk again Kind Regards, Sam > A *true* leak, in my opinion, is if performing some code sequence over > and over again (like what happens if you just do the same UI actions > repeatedly) causes the amount of unreachable memory to grow > continuously. Can Visual Studio detect such leaks? Do you see any of > them? > > And anyway, this "OMG GTK+ leaks memory" discussion has been had > several times already over the years. This parrot is dead. > > --tml > _______________________________________________ > gtk-app-devel-list mailing list > gtk-app-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list > -- Sam Spilsbury _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
