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

[Boehm, Hans]

Kevlin -

I think I can offer a bit more clarification w.r.t. C compatibility:

My impression is that vendors tend to favor solutions that don't
preclude them from doing interesting things in header files that are
shared between C and C++.  Hence there tends to be a push for low-level
solutions that work with both, plus possibly a higher level C++-only
solution that interoperates with it.  This is clearly more important for
certain parts of the interfaces than others.

Hence the push for both (1) and (2), and similarly for a low-level
C-compatible atomics package, as well as a higher-level one built on top
of it.

We also heard that the C committee is not currently working on a
language revision, though it may issue technical reports (which I guess
are essentially standard but optional extensions, and might have the
same impact for features shared with C++).  They appear to be looking to
the C++ committee to initially deal with these issues, and would clearly
like C-compatible solutions.

Other than that, this basically sounds right to me.

Hans

> -----Original Message-----
> From: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> .org.uk] On Behalf Of Kevlin Henney
> Sent: Tuesday, October 11, 2005 4:47 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: Re: [cpp-threads] C++ committee meeting in Mont Tremblant
> 
> 
> In message <434B3320.3080709 at metalanguage.com>, Andrei Alexandrescu 
> <andrei at metalanguage.com> writes
> >I think that's a great outcome, Hans, and I'd like to 
> congratulate you 
> >for so graciously taking ownership of this important project.
> 
> Ditto.
> 
> >I believe that the important tasks lying ahead are:
> >
> >1. Define the memory model
> >
> >2. Establish the atomic operations interface
> >
> >3. Develop the low- and mid-level API
> >
> >4. Leave room for future things (such as machine-wide atomic 
> sections)?
> 
> Yup, this looks good.
> 
> >If (3) is modeled after Boost, I am worried that it will be quite 
> >clunky. Sigh. Kevlin, Kevlin, where are you. Then, I'm not 
> sure why the 
> >low-level API would be necessary it the mid-level API is 
> well-designed 
> >(which implies it doesn't introduce inefficiencies or awkwardnesses 
> >that would force one to go down to unprotected C-style APIs).
> 
> The feedback that I'm getting is that there is some interest in the 
> stuff I've proposed, but that Boost currently has a bit more 
> mindshare, 
> and there is encouragement to flesh both out in more detail. 
> There are a 
> couple of on the UK panel that have expressed interest in taking this 
> further, so we are likely to try and organise something to do 
> this. I'll 
> let you know more when I know more.
> 
> However, one point that Hans mentioned was the idea of 
> standardising a C 
> API, eg POSIX, out of the box. On these different approaches, let me 
> repost and adapt something that I just posted to the UK reflector:
> 
> There appear to be basically three general approaches to introducing 
> threading facilities into C++ that are on the table at the 
> moment (this 
> is separate from the consideration of the memory model related work):
> 
> (1) Rebadge the C binding of pthreads or something very C and very 
> similar to it.
> 
> (2) Present threading to the programmer as a C++ library. 
> This is where 
> the Boost proposal and my proposal currently fit. Different 
> as they are, 
> they have more in common at this level than not.
> 
> (3) Extend the language with new concepts and syntax. This is where 
> Lawrence Crowl's ideas fit (and likewise, those not on the 
> table: Peter 
> Buhr's work, Concurrent C++, etc).
> 
> The common strength of (1) and (3) is that neither is necessarily
> C++-specific, albeit for quite different reasons. If C 
> compatibility is
> important, this becomes a deciding factor that pretty much 
> excludes (2), 
> unless (2) is seen as a wrapper for (1) (cf <stdio.h> and <iostream> 
> relationship). By being lowest common denominator and already 
> out there,
> (1) obviously has some kind of appeal. But from a C++ (or even C) 
> programming I can't say that the appeal is particularly great :->
> 
> OTOH, (3) offers a common way to extend both C and C++ in a way that 
> could be considered neutral to both languages. However, 
> politically and 
> practically this is more like a marathon steeplechase than the usual 
> standards obstacle course. There is no point in second 
> guessing what the 
> C committee would be prepared to standardise without also involving 
> them, which introduces more cycles into the whole process. I would 
> expect this process, even if successful, to be too lengthy to 
> fit into 
> the current C++ standardisation schedule. The inclusion of what is 
> effectively a new type system is likely to be seen as too much of a 
> disturbance on the core language.
> 
> There is of course the deeper question of whether any kind of C 
> compatibility is genuinely important. Although C99 has not actually 
> killed off C, it has made many people realise how much nicer 
> a language 
> it was in its previous incarnations. C is not dying, but I 
> don't see C99 
> as giving it a boost of life. How much more successful would 
> a successor 
> to C99 be, even if it included threading? My guess is that it 
> wouldn't 
> make as great a deal of difference in practice as it might in 
> theory. So 
> I am inclined to think that maybe a C-compatible approach is more 
> something that sounds nice than something that is genuinely needed or 
> will actually make a difference. Given that, I suggest that a C++ 
> approach should focus primarily on C++ and not try to carry 
> around any 
> more baggage than needed (it is already weighed down with 
> quite enough 
> :->).
> 
> So, leaving C compatibility to one side still leaves (1) but 
> also admits (2). In some ways, (1) is simpler, but it would 
> need someone to champion it. It is certainly not ambitious, 
> but it would get something that went by the name of a thread 
> library into the standard. However, I suspect 
> that it would leave a bad taste in the mouths of many.
> 
> When it comes to (2) we can then enter a debate as to library 
> style -- 
> Boost vs an executor-futures based approach -- but either way it is 
> understanding what would be most likely to be a sufficiently good 
> design, acceptable to the committee, embraced by programmers, etc. If 
> (1) or (3) is what is wanted, then there is little point in 
> wasting time 
> on (2). However, I don't really believe that (1) or (3) is what is 
> really wanted or expected.
> 
> Does anyone have any strong (or weak) views on these points?
> 
> Kevlin
> -- 
> ____________________________________________________________
> 
>    Kevlin Henney                   phone:  +44 117 942 2990
>    mailto:kevlin at curbralan.com     mobile: +44 7801 073 508
>    http://www.curbralan.com        fax:    +44 870 052 2289
>    Curbralan: Consultancy + Training + Development + Review 
> ____________________________________________________________
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk

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