|
Yes... you are right. C is a hard language to master, and memory management is indeed a hard task. Thanks for the book info, I had heard of it, never read it, I will certainly get me a copy! Our application is basically a ERP where we have raw materials that have to be purchased and inventory. These raw materials are used in a non-discrete manufacturing process to make printing inks, which are placed on orders and shipped, eventually to be invoiced. This is all written in house (Originally in Clipper before my time), now in C with GTK front end migrating to Quartz. I was treating all material (manufactured or purchased) as a structured data. The biggest change was I use to have some structure like typedef struct IsiComponent { gchar * aid; int nid; gchar *descripiton }; Using this as the private member (PIMPLE style) of a GObject and use get sets (properties) to it. I would than use the g_value_get_string on GValue to get a newly allocated string. I gave up on that idea.... real quick.... I realized that this is unnecessary roughness given that I am not looking write a portable API (for now), and having a series of get set functions is a lot harder to do, than creating simplistic routines that start with a structure like this: typedef struct IsiComponent { gchar aid[MAX_AID_LENGTH]; int nid; gchar descripiton[MAX_DESCRIPTION_LENGTH]; }; manipulate the data directly in the function. I still use calloc(1,sizeof(IsiComponent)) to initialize the original structure, but this way I don't initialize each individual member, especially since I am guaranteed that the description will not exceed 35 characters. I now simply copy the content of the record (ie database results) using strncpy and where formating is needed use snprintf, or in the case of nid simply nid = new_nid. I use the MAX_AID_LENGTH as the bounding length, and alwasy use ..n.. functions to only copy max count when dealing with string. I should have done this from the beginning, but I got overzealous with GTK and GObject :P I liked GObjects concept so I convinced myself I should be using it. I still like GObjects but it can stay in the GTK interface. I like Cocoa / Objective-C, but ultimately I'm thinking if I can keep my code low (C) and only use the most standard of libraries, I should have a set of structures and code that can plug into anything. The current production environment is using the GObject / GTK code, and it works well. I guess I'm finding this: strncpy(c.aid,actual_aid,MAX_AID_LENGTH); easier than g_object_set((GObject*)c,"aid",actual_aid,NULL); which actually has to switch the property to find which pointer to update. My only conclusion is I have most likely miss-used this tool and need to stop getting exited at every new API I find! Thanks for all your help J, I would have not gotten this far as I did, without it :) Hopefully as I learn more I can help back ;) From: jralls ceridwen us Date: Tue, 27 Jul 2010 20:05:53 +0200 To: gtk-osx-users lists sourceforge net Subject: Re: [Gtk-osx-users] Is it me or GTK? 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 Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. See how. |