Wow, thanks for all the info! I had thought about having arrays for everything, but didn't want to because I wouldn't know how many of each struct I would have in each module. But if what you're telling me about malloc and free is true, maybe I should change that behavior… Until now I've had no real drama with them, besides the processor getting stuck after 10 minutes of hard work or so. But it seems better to just migrate to using static arrays… Seems safer anyway. The real problem with it is that I would have to know the memory requirements at compile time, which I personally dislike (coming from the dynamic object oriented programming world).
Thanks for all the tips! --------------------------------------- Sergio Campamá [email protected] On Aug 19, 2011, at 1:50 PM, Chris Liechti wrote: > Am 19.08.2011 17:53, schrieb Sergio Campamá: >> Thanks for the insight into the problem. The thing is that I have a >> task scheduler, a linked list that, well, lists the tasks to >> perform... Since linked lists are dynamic in nature, I need malloc to >> create the new "task" and append it to the list.. And after the task >> is done, I free the task and >> go on to the next one... The other place I use linked lists is to >> maintain a list of timers that the application uses to signal certain >> events... after >> the timer activates, it also gets freed... >> >> So that is why I need malloc and can't (or don't know how) to do it >> with other types of dynamic storage, or static. (On that subject, >> what other types of dynamic storage exist?) > > just because you use a linked list does not automatically mean that you > also need dynamic memory. > > i also implemented an event handler that uses a linked list. an event_t > is a struct with the information about the event. each module that wants > to use an event allocates its own object as [static] global. each event > can only be enqueued once. > > pro: > - each module is responsible for its own memory > - all statically allocable > - exactly as many event objects as are needed > > con: > - entire struct in RAM, including the function pointer which will not > change. > > > an other possibility is to have an array of objects [structs] and your > own allocate (and free) function that returns pointers to that array. > that way you also get statically allocated memory. > > pro: > - all statically allocable > - also possible to use indexes instead of pointers. indexes are easier > to check if they are valid (compared to pointers). and a single byte > is usually enough. > > con: > - you also have to make two design descisions: > - how many objects will be needed (array size). do you go for a > typical size or worst case size? > - what will you do if no object can be allocated? > (if selected size < worst case size) > - it does not automatically adjust to the application (e.g. if you have > different variants. the solution above only uses the RAM when the > modules are linked) > > chris > > ------------------------------------------------------------------------------ > Get a FREE DOWNLOAD! and learn more about uberSVN rich system, > user administration capabilities and model configuration. Take > the hassle out of deploying and managing Subversion and the > tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 > _______________________________________________ > Mspgcc-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mspgcc-users ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Mspgcc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mspgcc-users
