Hello Michael,
2017-05-16 11:27 GMT+02:00 Michael Oswald <[email protected]>:
> Hi,
>
> Without being directly a Muse developer, maybe a few comments:
>
> > On 2017-05-13 08:40 AM, Robert Jonsson wrote:
> >> Hi guys,
> >>
> >> I've been experimenting with adding RtAudio support to get additional
> >> audio backends, sadly RtAudio works really badly unless you can have
> >> exceptions (not a good design of that part of the library IMO, but
> >> still).
> >> Thought I would just ask, as we define no-exceptions, is there a known
> >> reason for this or is it just out of old habit?
> >> Probably the binary is a little bit smaller with no-exceptions but
> >> otherwise I'm uncertain it makes any real difference.
>
> Exceptions bring a few headaches with them, so probably it was a good
> decision. At work I am developing on a mission control system and have
> been bitten by exceptions quite some time, as it is quite hard to get
> exception safe code.
>
> Still, I have not really a deep knowledge of the Muse Code Base,
> therefore of course, the decision should be up to you.
>
> So please, see this just as some comments and random thoughts :)
>
> Just some points:
> - Exceptions need everything to be safe, which often means heavy usage
> of RAII for resource management, especially of Mutexes and memory (i.e.
> means the use of Smart Pointers). Sometimes this needs serious
> refactoring to get there.
> - There are different exception guarantees, that should be met
> e.g. from Stroustrup himself: http://www.stroustrup.com/except.pdf or
> here from the boost folks:
> http://www.boost.org/community/exception_safety.html
> - be careful with exceptions and multi-threading. While there are no
> asynchronous exceptions in C++ (which provide another can of worms,
> that's why Java dropped them again), the pthread library, which on Linux
> is the native threading library uses the C++ exception mechanism under
> the hood to cancel threads. If you call pthread_cancel (or a threading
> library does that under the hood e.g. boost::threads) in reality it
> raises a C++ exception that MUST NOT be caught. We had this two times in
> the mission control system, where we added a catch(...) clause and the
> process aborted with FATAL: exception not rethrown because someone used
> a pthread_cancel. Most people are not aware of this.
> - the only real guarantee you have from methods with nothrow, all
> other methods can in principle throw all kinds of exceptions, no matter
> what throw specifiers are there (e.g. std::bad_alloc in principle
> everywhere where operator new is used).
>
> Now working a lot in Haskell (which also has exceptions and also
> asynchronous exceptions) I came to really don't like them since
> especially because of Haskells lazy evaluation you often don't know when
> the exception can and will be triggered. So currently I avoid them as
> much as possible.
>
> Anyway, in case of RtAudio maybe it would be possible to provide a thin
> wrapper around it to catch them and convert them into error codes?
> Depends of course on code division, build system etc.
>
Thanks for your insight and yeah, I'll try to investigate if we can have
exceptions enabled only in the library interfacing RtAudio. I'm thinking
however that us enabling exceptions shouldn't make such a difference as
long as we don't use them, with RtAudio it will be two try-catch blocks,
that should be all.
Apart from it's exception-use I really like RtAudio, very straightforward.
There are other potential libraries for this purpose, for instance
libsoundio looks promising but it's API is much more complex.
Speaking of coding and new languages, I'm doing Go-lang coding at work
since half a year and it has been a really great experience this far :)
Regards,
Robert
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
