<br><br><div class="gmail_quote">On Sun, May 23, 2010 at 10:03 PM, Joshua D. Boyd <span dir="ltr"><<a href="mailto:jdboyd@jdboyd.net">jdboyd@jdboyd.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
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.<div>
<div class="h5"><br></div></div></blockquote><div><br>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. <br><br>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. <br>
<br>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).<br>
<br>--p<br><br></div></div>