begin quoting James G. Sack (jim) as of Sat, Sep 30, 2006 at 01:46:18PM -0700: > - - - > continuation from main list of the thread: > Re: Circular buffers (Was: C-based data structures library (like Boost > but for C)?) > - - - > > <CONTENT-WARNING > beware-list="armchair-expert, handwaving, computer language ramblings" />
/me laughs > Stewart Stremler wrote: [chop] > > But it's that first trick I don't remember how to do. Wanna pick > > this up in LPSG? > > Hmmm, it's been a long time, but I think I always relied on debug-build > behaviors that diddled malloc/free . In this simple case, I suppose one > might consider a manual substition of myMalloc myFree wrappers -- but > somebody's already done that for us, I'm sure. > > Hmmm, know anything about mtrace (man 3 mtrace -- from glibc-utils)? Nope. But the manpage pointed me to malloc_hook, which looks like what we need. I found another approach at http://okmij.org/ftp/syscall-interpose.html ...which uses ld to basically accomplish what I was thinking of doing. I have another thought (involving function pointers) that I might look at. Dunno if it would work, however. > I also see mention of memwatch and dmalloc. > These above found via > Memory Leak Detection in Embedded Systems > http://www.linuxjournal.com/article/6059 These don't seem to lend themselves to unit-testing, alas. > Now, I've also heard of valgrind, but never used it. I'm sure a > 'regular' c-programmer must know about and use all these things, everyday. Again, not something that lends itself to using in a unit-test. [snip] > Looking at the original question, as well as past posts on related > subjects, it is fun to ask/remark: > > People have probably been writing circular buffer code since before > Carl was in undergrad school -- why don't we have some nice reusable > choices in widely available libraries. Because most of the time, the buffer is tightly tied to the type of data being buffered, and it only takes a page or two of code to implement. A library version will by necessity be more generic, and thus contain excess code and overhead. I would suspect that the greatest need for ring buffers is in low-level drivers, where tight coupling to ASM is king. Not something that you'd use a library function for. > C does not make it easy to write object-like code. But it does lend itself to modular programming, which is most of the way there. And, often, that's good enough. > One thing in > particular, you have to use some type-casting which kind of detracts > from the benefits argued for static typing. Hmmm.. wonder what > Objective-C is like? Should I write up a version of the circular buffer in Objective-C? You can contrast and compare. :) (Hm. There's nothing already in the foundation classes. I'm suprised.) > Thinking about Chuck Esterbrook's posting, makes me admit that > Microsoft's (or whoever they stole it from) work on Common language > Runtime addresses a long-standing need. Why? Hasn't this need been fulfilled more than once? > 'course, I sure would like the > library code to be open, because that's one of the big things that > chased me away from MS originally. It's now an even stronger requirement > (open code), given the potential for bad behavior by the bad guys. Heh. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
