[LAD] Looking for an introduction to rt programming with a gui

Paul Davis paul at linuxaudiosystems.com
Mon May 24 02:53:59 UTC 2010


On Sun, May 23, 2010 at 10:03 PM, Joshua D. Boyd <jdboyd at jdboyd.net> wrote:

>
> I think it isn't difficult to read because it is C++ or Boost.  It is
> difficult to read because it involves concepts like promises and futures,
> which are advanced topics that a lot of people (myself included) aren't
> adequately familiar with (at least not without referring to a cheat sheet).
>  If we rewrote that with C types using a C type future/promise system, I'm
> not sure it would be any easier to read for those of us who don't
> intuitively grok promises and futures.
>
>
what he said. we can extend this to a lot of boost-covered stuff. a C
implementation of boost::optional would be similarly opaque and clumsy, i
think.

i also can't begin to imagine how to implement scoped-lifetime objects in C.
even without exceptions (which admittedly do cause some conceptual pain in
C++), the ability to know that wherever you return from within a function,
relevant local objects will be cleaned up has a significant simplifying
effect on the design of a function.

so yes, you can certainly get along without these ideas and write very
sophisticated software. the issue is really about whether you want to. when
i went to write a functor class a few months ago, i got about 90% of the way
there in a few hours. then i went and read the boost headers and realized
there was an entire universe of semantic details that i was overlooking and
that to get all the way "there" would take me weeks, assuming i ever got
there. so i could (a) do without functors or (b) use the boost
implementation. i chose (a).

--p
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100523/fdc6476c/attachment.html>


More information about the Linux-audio-dev mailing list