On Sun, May 23, 2010 at 06:58:42PM -0400, Paul Davis wrote: > clearly, you've not used shared_ptr.
I'm not using them, for various reasons: 1. Looked at the documentation and decided I didn't want this. Have you counted the number of caveats ? Just using an unnamed shared_ptr as function argument can be enough to invalidate the whole thing. 2. At least in the type of apps I write (DSP, RT), memory management should IMHO be explicit. Without that, you don't even have any idea if how much memory your code is using at any time, nor when some of it will be freed - it could very well happen at an unconvenient time. If you have to keep copies of a smart pointer just to make shure it won't call delete[] while in a RT context, then the whole point is lost. 3. I use C++, and all classes I write are designed to clean up after themselves, just as all threads are designed to terminate themselves explicitly and cleanly. Making sure that these things are correct takes some work, but the reward is a level of confidence I wouldn't have with any 'automated' way of doing this. It also forces you to _think_ about these things, which results in cleaner design. 4. In those cases where dynamically allocated objects move around between objects or threads and it's not clear who should take care of managing them, very often following some simple rules solves the problem. For example, the message objects used by clthreads are in their basic form not even reference-counted. The rules for using them are simple: when you receive one, or create one, you own it. After use, either delete it or send it to some other thread, and in boht cases assume it doesn't exist anymore. > i am glad to hear, however, that you've never used longjmp/setjmp in your > code, or thread local storage. I *do* use setjmp/longjmp in one case, when interfacing with libpng which uses them for error recovery. I've never understood what's the point about the horrible thread local storage API. All threads I use are C++ objects, any non-static data members of such a class are local to the thread. That's all I need. You need to bootstrap thr_start() via a static C function once (using the void *arg as object pointer) and that's it. You could do the same in plain C as well, just putting all thread local data into a struct. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte ! _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
