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

Joshua D. Boyd jdboyd at jdboyd.net
Mon May 24 02:03:20 UTC 2010


On 05/23/10 16:22, Chris Cannam wrote:
> On Sun, May 23, 2010 at 8:44 PM, Chris Cannam
 > On Sun, May 23, 2010 at 9:41 AM, torbenh<torbenh at gmx.de>  wrote:
 >> but i find the equivalent c++ easier to read.
 >> assuming we have a proper modern c++ osc lib:
 >>
 >> boost::unique_future<OscMsg>
 >> osc_recv (OscPeer peer, std::string path)
 >> {
 >>         boost::shared_ptr<  boost::promise<OscMsg>  >  spromise( new 
boost::promise<OscMsg>  )
 >>         peer.add_handler( path, [=]( OscMsg msg )
 >>         {
 >> [...]
 >
> <cannam at all-day-breakfast.com>  wrote:
>> I have to say this combination of Boost plus Weird Stuff From The
>> Future is no more readable to me (as a long-time C++ programmer) than
>> the Clojure example.
>
> ... by which I don't mean to imply that I can't understand it
> (although, with C++, there is always the possibility that I _think_ I
> can understand it but am sadly mistaken because of some weird shit
> happening behind the scenes).  I just mean that I can't simply read
> it.
>
> This may be one really serious advantage for the everything-in-C types
> -- a competent C programmer can understand any C, whereas C++ is big
> enough to have many different "schools of C++" which are mutually
> unintelligible without further study.
>
> That's also the seed of its popularity, I suppose -- everyone can
> write the way they like in it, and if you can't work out how to do it
> properly, you can always drop back into C.

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.



More information about the Linux-audio-dev mailing list