Re: [Gtk-osx-users] Is it me or GTK?

On Jul 27, 2010, at 6:34 PM, Shawn Bakhtiar wrote:

Yes, GDB is my friend, and yes as I had surmised before, the issue was a leak on my part.

However, given all the checks that are in the API (and I am stipulating that the OS X back-end is still a little weak), should I as the user be able to so readily forward leaks to the API? I see a lot of g_return_if_fail macros when I sift though the API code.

I am mostly running into this problem as I transition our core code off of GObject (the non interface part of our code), and starting to use static size arrays instead of calloc / free. I guess what surprises me is that there are no boundary checks (if I say it correctly) ?

No argument that the OSX back end is still weak, though it has improved markedly from a year ago.

Yes, you're working with C, a glorified assembly language. Leaks and pointer problems go underground and bite you when and where you least expect them. There are lots of ways to protect against leaks, but they mostly involve using more sophisticated languages than C (C++ has several idioms for memory management, and many other languages including Objective-C, C#, and Java provide garbage collection.)

g_return_if_fail is a flavor of ASSERT; it's generally for preventing things like dereferencing null pointers. It doesn't cause leaks, but it does let you know that you're passing bad arguments.

Moving away from GObject and replacing it with what? (C++, I hope, unless you're targeting Cocoa in which case it should be Objective-C. You don't *even* want to try to roll your own object-oriented code in C. GObject is bad enough!)

What do you mean "static size arrays instead of calloc"? Allocating a giant array on the stack instead of a correctly-sized one on the heap? That's OK if the array is local to the function, but if you have to pass it around, it's going to make your code a lot slower and greatly increase the risk of pointers-to-objects-that-aren't-there-anymore. If you mean static array variables, well, they have their uses, but aren't thread safe and can be a problem if you get the size wrong.

I suspect that you need to step back a bit and think about what you're trying to accomplish. Moving away from GObject is likely to require a careful and thorough redesign rather than a simple refactoring.  (If you haven't memorized Martin Fowler's "Refactoring", now would be a good time to run through it again.)

John Ralls

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]