>> Ok, lets discuss this, people, speak up so we can do this 'right' >> in one go (and quickly too) ;-) > I'd rather not rush into something we regret in 6 months...
Let me rephrase that: with more feedback (preferably with fears/ reservations) the bottlenecks can be identified more quickly. Like I said, the main thing is to do it right. > Not trying to be a damp squid, but can we have a fully fledged and working > example before too long. I have some concerns that this stuff is dropping > us into a mire of complication... Please tell us your worst fears :-) > Hopefully a full example will allay my fears as you guys keep > telling us how easy this stuff is to write :) Well, to put it simply, the 'memory system thing' is just an abstraction layer. If you implement a memory system you have to provide a number of functions specific to your memory system: malloc, realloc(optional), free(optional, provided you have a reset and destroy), reset(optional, provided you have a free) and destroy(optional, provided you have a free). And another optional pre_destroy. The destroy function is only allowed to free memory, nothing else (the reason for this is that it could be skipped). If you need to close files or whatever, do it in pre_destroy. Hmm, ok, I said I was going to put it simply... hmmm. Oh well :-) > Also, a test program should be added as soon as this is > "buildable" so it's working can be verified as once committed Ah, ok, I was hoping that you guys could fill in the APR blanks that were in there (I'm not enough into APR to know all constant names and conventions you use). > we're into the multi-platform arena, but you knew that, right? :) Yes, I know :) [guess why we are tracking apr development] For the record, as far as I know I only used standard c stuff in the memory system code, so this should be portable across all platforms. Please correct me if I'm wrong. > david Sander
