On Sun, May 23, 2010 at 10:03:20PM -0400, Joshua D. Boyd wrote:
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(a)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(a)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.
yeah. but without understanding what a promise is. you dont even
understand what @p in clojure means.
now try to find that out using google :)
the point i wanted to make is that when comparing young modern languages
to current c++03 (which practically is just a small correction to c++98)
c++ looses.
but c++0x can keep up.
--
torben Hohn