On Sun, May 23, 2010 at 10:03 PM, Joshua D. Boyd <jdboyd@email-addr-hidden> 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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon May 24 08:15:02 2010
This archive was generated by hypermail 2.1.8 : Mon May 24 2010 - 08:15:02 EEST