On 2016-08-18 02:12, termtech wrote: > There's a general mixture depending on who's coding and what the task is. > Tons of STL and Qt template stuff. But no boost, yet. > > I think you are correct in that nowhere do we use STL or Qt for the > actual allocation of memory. Just malloc or new, and some system functions > for special aligned memory for audio buffers. > > When we use STL containers we usually just use the default allocator, > but there are a few sections where a special pool is used for RT. > I want to use pools more because there are still places in the RT code > which may cause a container to allocate in RT. > > I looked at boost a few times. I know it has good features for these things. > Ardour uses (used?) it. But we've never used it in this app before. > Inertia...
Ok. Sounds like a fairly normal project :) The system I normally work on is also a very wild mixture (20 companies developed it with different knowledge, coding styles etc), so I know that very well. Yes, Ardour relies also on boost quite heavily, mainly for the smart pointers, threading and the signal libraries which they use for the callback mechanism in addition to gtkmm's things. > Myself, I know that usually you're supposed to prefer functions from > the operating system over C or C++ functions. > For example in Windows I usually use their allocation functions, > especially for the more esoteric memory needs. Ok. > In MusE we probably /should/ be using all Qt functions all the time. > But we don't always. > Maybe it's a little bit like 'hedging your bets' - maybe left over from > the old days when MusE was young and Qt was not a certainty yet > at version 2 (or less?) - where you hope for best cross-platform > compatibility and so take the lowest common tool which is STL. > Some of the code is really old so maybe that's why there's > heavier emphasis on STL. > And I tend to code as 'when in Rome...' so I follow what others > have done in the project and thus lean towards STL more often. > STL seems more portable. At least it's a feasible approach. Sometimes you have to be pragmatic and redesigning something in C++ can take some time. > With your experience, what do you think of our template lib situation? > Bit of a dog's breakfast? > Do you recommend that we stick with only one template lib and > is a mixture a bad thing? Not necessarily. Each library has it's strenghts and weeknesses. Boost concentrates on more "low level" things like smart pointers, containers, algorithms, bridging incompatibilities, parsing etc. Poco is more high level, has complete frameworks for threading, network stuff (up to ready HTTP servers), data access and a hell lot of cool stuff. But e.g. if you compare the smart pointer implementation, then boost has the advantage that it can use forward-declared types which allow forward declarations of smart pointers, while Poco smart pointers need full defined types which can sometimes lead into include cycles. It's these subtleties which then finally decide what you can use. And it would be a shame to rule out the use of smart pointers because of this. That's why we settled on the Boost/Poco/STL combination and some other libraries for special tasks. I haven't had the chance to work with Qt a lot, so I can't comment much on it's capabilities besides the GUI stuff. > Florian wanted to start MusE-3 from scratch with consistent use > of a boost-like library, I forget which, and using locks instead our > current 'synchronized just in time' realtime model. The consistent use of such a library is always a good idea, just (in my opinion) it's good to keep an open attitude if the library starts to limit certain things too much (e.g. the missing forward-declaration possiblity of Poco smart pointers above). As for the locks, it depends. Always keep in mind, that locked functions don't compose well, so this has it's own challenges and it's really hard to get that right. I got bitten by this quite some times and tend to use lockfree structures if possible (and available). For some projects I switched to Haskell and the Software Transactional Memory and this is a huge stepup but it's currently not available in C++. I'll have to look at the realtime model in MusE to understand how it works. > > Ask away if you need help navigating MusE. Thanks a lot! I most probably will. lg, Michael ------------------------------------------------------------------------------ _______________________________________________ Lmuse-developer mailing list Lmuse-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lmuse-developer
