On Sun, May 23, 2010 at 10:03 PM, Joshua D. Boyd <[email protected]> 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
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
