On Jul 27, 2010, at 6:34 PM, Shawn Bakhtiar wrote: 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.) Regards, John Ralls |