[cpp-threads] C++ committee meeting in Mont Tremblant

Andrei Alexandrescu andrei at metalanguage.com
Tue Oct 11 17:38:16 BST 2005



Peter A. Buhr wrote:
>    I think there's a tad of misunderstanding in here, caused by the fact 
>    that C++ is unusual in a particular way.
> 
>    Unlike most languages, of which parsers are just a tiny part of the 
>    processing chain, C++ has a horrendously big complicated syntax. That 
>    creates problems so wicked, that people who haven't actually tackled 
>    them can hardly imagine them.
> 
> No misunderstanding here at all. I have been dealing with the syntax in C and
> C++ for well over a decade and I'm intimately familiar with the hostile
> syntactic environment of both languages. I have written a complete grammar for
> C with heavy extensions (Cforall) and concurrent extensions for C++ (uC++). In
> fact, the only "really" difficult part of the C/C++ syntax is the onion-wrapped
> declarator syntax. The rest is reasonably straightforward.

That I totally disagree with (and is the typical answer of people who 
haven't actually written a full C++ parser... C isn't even getting 
close), but my point it's becoming irrelevant. Just the algorithm that 
figures out what f is called (and perhaps instantiated) in the call f(x) 
in the presence of overloading and templates is a few pages long.

> I think we have to identify our audience, and target a solution for this
> audience. The memory-model people have a very small audience doing very
> precise, complex bits of concurrency at the ragged edge of performance.  We now
> need to address the other large bulk of the concurrency audience and help them
> do their job. And this group is significantly more than just the scientific
> computation crowd, which is only a small percentage of all concurrent
> programmers.

With all due respect, I disagree with that too. There are plenty of 
threading frameworks that define what happens "in 99% of the cases" and 
leave some fuziness by the corners. We should NOT care for those. The 
right way to go is figuring something that guarantees what works and 
what doesn't no less than 100%. Defining abstractions for mutexes, 
events, and locks will be the simplest part.


Andrei

-- 
cpp-threads mailing list
cpp-threads at decadentplace.org.uk
http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decadentplace.org.uk






More information about the cpp-threads mailing list