jcoffin@taeus.com (Jerry Coffin) wrote in message news:<MPG.1a77bdd65ad5ee76989c37@news.clspco.adelphia.net>...
> In article <slrnc0q38a.1eg.do-not-spam-benh@tin.bwsint.com>, do-not-
> spam-benh@bwsint.com says...
>

 [ ... ]

> > It is not essential to have a thread API, but I believe the language
> > specification must allow for multiple threads of control and must
> > specify some basic thread-safety guarantees for multi-threaded
> > implementations (e.g. multiple threads may read the same container at
> > the same time).  Thread creation, deletion and synchronisation can be
> > left as "implementation-specified".  That would at least make it
> > possible to write generically thread-safe code within the standard.
>
> Sort of.  I think a better option would be to leave creation and
> deletion implementation defined, but require at least a few simple
> synchronization primitives -- which would end up being (nearly?) NOPs on
> a system that only provided single threads.  That would provide the
> primitives necessary to write the thread-safe containers, etc., in a
> portable fashion, while imposing only the most minimal extra extra for
> those who didn't want to really support multi-threading.
>
> [ ... ]
>
> > What if they're optional, as Stroustrup proposes?
>
> That depends on how optional they are.  If their presence is optional,
> then it's nearly the worst possible scenario -- the committee has to
> spend just as much time and effort on getting them right as if they're
> mandatory (and POSIX proved that this is decidedly non-trivial).  At the
> same time, all that effort is mostly wasted, because portable code can't
> take any advantage of it at all.
>
> Another possibility would be to make them optional for now, but promise
> that in the next version of the standard (or some other specified time)
> they'd become mandatory.  This is only slightly better, but at least it
> gives an assurance that code that uses them will eventually become
> portable, and gives vendors real motivation to start working on
> providing it.  Overall, not nearly as bad as purely optional, but not
> really a whole lot better either.
>
> A third possibility would be to make the _presence_ of the header(s),
> functions, etc., all mandatory, but allow thread creation to fail on
> systems that don't support multiple threads, and define synchronization
> so it can be implemented as (nearly?) NOPs on single-threaded systems.
> With some care, this would allow programmers to write code that portably
> uses multiple threads on systems that support it, but remains portable
> to single-threaded systems as well.
>
> I don't consider any of these truly ideal, but IMO, the last is at least
> less bad then the others.

Well, what I assume Stroustrup has proposed is to define some notion of
"optional" with very strict rules. Today, a "free-standing" C++ implementation
doesn't have to support any header - except a few ones, maybe? - but a "hosted"
implementation has to support all, to qualify as "standard".

A nice idea would be to define some parts of the library that can be
"optionally" left out IF the platform has some specified restrictions:
On a platform without console or file I/O the library could leave out
cin, cout rsp. filestreams - but should it provide stringstreams? - and on
a platform with no proper thread support it could leave out thread creation
stuff. IMHO even those implementations should be required to provide a few
"dummy" simple synchronization primitives, anyhow.

Of course, the term "proper" thread support may lead to discussion for certain
platforms.

>
> --
>     Later,
>     Jerry.
>
> The universe is a figment of its own imagination.
>
> ---

Uwe

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <a%2Pb.1944$LM4.741@nwrdny03.gnilink.net>, hyrosen@mail.com
says...

[ ... ]

> But Ada, standardized in 1983, has concurrent programming defined within
> the language, and it has stood the test of time. The 1995 upgrade added
> some further improvements, and the 0x process may add a few more, but the
> basic model is unchanged and works fine on a large variety of platforms.
>
> The secret to success is to concentrate on what the language should be able
> to do, not how to bind it to existing implementations.

That depends a bit on what you're trying to accomplish. If your idea is
simply to provide the end programmer with some way to use threads
portably, then you're almost certainly correct. C++ (like C before it)
has traditionally taken almost exactly the route you say won't succeed:
providing a relatively thin layer of binding over an existing
implementation.

> As the simplest
> example, any attempt by C++ to address concurrency must specify that the
> initialization of a static variable happens exactly once, regardless of how
> many concurrent execution streams attempt to access that variable at the
> same time.

I doubt anybody will have major heartache with some rules that basically
say "even when there are threads, the rules to which you're accustomed
won't change."  The problem is that while those are useful, you have to
go a bit beyond them to actually provide threading.

> Assuming that the computational model isn't completely lunatic,
> binding it to existing threading models will be possible, and possibly easy.

 That depends heavily upon what you define as "lunatic".  Just for
example, nearly all existing attempts at supporting LOTS of processors
(e.g. tens of thousands) has resulted in much looser coupling than most
of us are accustomed to.  The result is that a lot of things we more or
less take for granted on single processor and small-scale multiprocessor
machines aren't true anymore.  If it was easy to provide the same
capabilities within the model to which most of us are accustomed, I'd
agree that it was probably lunacy to change the visible model a great
deal.  So far, however, I've seen little evidence that this is the case,
so I'm hard put to call these changes lunatic -- even if at times
they're almost enough to turn the programmer INTO a lunatic.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <aec458c5.0401220408.4225b527@posting.google.com>,
schnitker@sigma-c.com says...

[ ... ]

> Well, what I assume Stroustrup has proposed is to define some notion of
> "optional" with very strict rules. Today, a "free-standing" C++ implementation
> doesn't have to support any header - except a few ones, maybe? - but a "hosted"
> implementation has to support all, to qualify as "standard".

Right. I think it's that coarse granularity that makes it usable.  It
means that if you're trying to provide a compiler for a typical desktop
system, there's no real option: you have to provide the entire standard
library.  On embedded systems, the situation isn't quite a nice, because
even though a free-standing implementation doesn't have to supply most
of the standard headers, most provide at least partial versions of a
pretty fair number of them.

> A nice idea would be to define some parts of the library that can be
> "optionally" left out IF the platform has some specified restrictions:
> On a platform without console or file I/O the library could leave out
> cin, cout rsp. filestreams - but should it provide stringstreams?

The problem is deciding what qualifies as not providing console I/O (to
use one of your examples).  To use one of your examples, would this mean
that an embedded system with a single-line LCD display would be required
to support the full console I/O model, even though most of it makes
little or no sense under the circumstances?

> - and on
> a platform with no proper thread support it could leave out thread creation
> stuff. IMHO even those implementations should be required to provide a few
> "dummy" simple synchronization primitives, anyhow.
>
> Of course, the term "proper" thread support may lead to discussion for certain
> platforms.

Not "may" -- "will".  In fact, from what I've seen of standards
committee meetings, there'll be a LOT of discussion, some of it almost
inevitably bordering on (if not intruding into) the acrimonious realm.
Don't get me wrong: from what I can see, most people on the committee
really work hard to do things as well as possible, rather than just
present what they're already doing as being the sole correct way to do
things.  Nonetheless, if you've used a particular threading model for a
decade (or more) with great success, it's likely to make it a little
difficult to sit idly by when/if somebody charges that it's
fundamentally broken in its entirety, and the only way they'll even
consider voting for the standard is if it embodies a model that's
fundamentally opposed to it in almost all respects.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Thu, 15 Jan 2004 08:15:56 -0500, Robert W Hand wrote:

[ crossposted to comp.std.c++, the only place I think this question can be
answered ]

> boost seems to be special because much of it may end up in a future
> C++ standard.  Does anyone know if the future standard will include
> none, some, most, or all of boost?  Still undecided?  If at least some
> will end up in a future standard, then it is reasonable to make boost
> on-topic now.

[ Note to comp.std.c++, the remark on on-topicness is about acllc-c++ ]

On second thought, boost is to large to be on topic in acllc-c++, but as
2005 draws near it is very important to look ahead and see what of boost
will be incorporated. If this is in any way clear, I propose to consider
discussions about those topics on topic for this group.

M4

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Martijn Lievaart wrote:
> On Thu, 15 Jan 2004 08:15:56 -0500, Robert W Hand wrote:
>
> [ crossposted to comp.std.c++, the only place I think this question can be
> answered ]
>
>> boost seems to be special because much of it may end up in a future
>> C++ standard.  Does anyone know if the future standard will include
>> none, some, most, or all of boost?  Still undecided?  If at least some
>> will end up in a future standard, then it is reasonable to make boost
>> on-topic now.
>
> [ Note to comp.std.c++, the remark on on-topicness is about acllc-c++ ]
>
> On second thought, boost is to large to be on topic in acllc-c++, but as
> 2005 draws near it is very important to look ahead and see what of boost
> will be incorporated. If this is in any way clear, I propose to consider
> discussions about those topics on topic for this group.

The Library Technical Report (TR1) should be released in the not-too-
distant future and will probably be incorporated into the next version
of the standard.

According to the standards committee web site, the following proposals
have been accepted for TR1.  I have noted in brackets the libraries
that they are based on.

N1402, Polymorphic Function Object Wrapper.  [Boost function]
N1403, Tuple Types                           [Boost tuple]
N1422, Mathematical Special Functions.       [C99]
N1424, Type Traits.                          [Boost type_traits]
N1429, Regular Expressions.                  [Boost regex]
N1432, Enhanced Member Pointer Adaptor.      [Boost mem_fn]
N1450, General Purpose Smart Pointers.       [Boost smart_ptr]
N1452, Extensible Random Number Facility.    [various]
N1453, Reference Wrapper.                    [Boost ref]
N1454, Uniform Method for Computing Function Object Return Types.
                                             [part of Boost bind
                                              and Boost lambda]
N1455, Enhanced Binder.                      [Boost bind]
N1456, Hash Tables.                          [various]

I do not know whether any more libraries are expected to be
incorporated into the next standard.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

do-not-spam-benh@bwsint.com (Ben Hutchings) writes:

> The Library Technical Report (TR1) should be released in the not-too-
> distant future and will probably be incorporated into the next version
> of the standard.
>
> According to the standards committee web site, the following proposals
> have been accepted for TR1.  I have noted in brackets the libraries
> that they are based on.
>
> N1402, Polymorphic Function Object Wrapper.  [Boost function]
> N1403, Tuple Types                           [Boost tuple]
> N1422, Mathematical Special Functions.       [C99]
> N1424, Type Traits.                          [Boost type_traits]
> N1429, Regular Expressions.                  [Boost regex]
> N1432, Enhanced Member Pointer Adaptor.      [Boost mem_fn]
> N1450, General Purpose Smart Pointers.       [Boost smart_ptr]
> N1452, Extensible Random Number Facility.    [various]
> N1453, Reference Wrapper.                    [Boost ref]
> N1454, Uniform Method for Computing Function Object Return Types.
>                                              [part of Boost bind
>                                               and Boost lambda]
> N1455, Enhanced Binder.                      [Boost bind]
> N1456, Hash Tables.                          [various]
>
> I do not know whether any more libraries are expected to be
> incorporated into the next standard.

N1550, New Iterator Concepts
N1530, Iterator Facade and Adaptors [Boost.Iterator]

You can see updated versions of these at
http://www.boost-consulting.com/boost/libs/iterator/doc

Regards,

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Ben Hutchings" <do-not-spam-benh@bwsint.com> wrote in message:
benh@tin.bwsint.com...

>
> According to the standards committee web site, the following
proposals
> have been accepted for TR1.  I have noted in brackets the libraries
> that they are based on.
>

<snip>

>
> I do not know whether any more libraries are expected to be
> incorporated into the next standard.
>
>

Is it naive to hope that we might yet get standard <thread> and
<socket> headers in C++0x?

Jonathan


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <buca4b$fvpgt$1@ID-216073.news.uni-berlin.de>,
technews@kangaroologic.com says...

[ ... ]

> Is it naive to hope that we might yet get standard <thread> and
> <socket> headers in C++0x?

I'd guess the chances are slim and none: slim for <socket> and none for
<thread>.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

jcoffin@taeus.com (Jerry Coffin) wrote in message news:<MPG.1a73b916767b59cf989c22@news.clspco.adelphia.net>...
> In article <buca4b$fvpgt$1@ID-216073.news.uni-berlin.de>,
> technews@kangaroologic.com says...
>
> [ ... ]
>
> > Is it naive to hope that we might yet get standard <thread> and
> > <socket> headers in C++0x?
>
> I'd guess the chances are slim and none: slim for <socket> and none for
> <thread>.

Interestingly, both were included in the early "things we might want to
include into the standard library" bullet list used by BS to start the
C++0x process. Threads were mentioned as something "we shouldn't make
a built-in feature of the language, but make it a(n optional?) part of
the standard library, maybe with some bit of language support".

I have not yet seen any indication for a change of mind.

Clearly, neither will be included in the TR1, but after the TR1 is done
the standard committee might want to consider including other new library
parts as well as polishing the TR1 ones (plus correcting/augmenting some
of the C++98 ones).

IMHO this depends strongly on whether there will be good candidate solutions
available then. If the boost.thread matures quick enough, or if some other
approach fits good enough, the chances may improve. (Perhaps it also depends
on some way to define optional things, because some systems will not be able
to support what would be required by a really useful standard library part.
But, hey, we have IOStreams even if some systems can't support them - because
they have no console or file IO whatsoever.)

>
> --
>     Later,
>     Jerry.
>
> The universe is a figment of its own imagination.
>

Have fun,

Uwe                      ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <aec458c5.0401182320.27bdd9fa@posting.google.com>,
schnitker@sigma-c.com says...

[ ... threads and sockets ]

> Interestingly, both were included in the early "things we might want to
> include into the standard library" bullet list used by BS to start the
> C++0x process. Threads were mentioned as something "we shouldn't make
> a built-in feature of the language, but make it a(n optional?) part of
> the standard library, maybe with some bit of language support".
>
> I have not yet seen any indication for a change of mind.

Probably not, at least on his part.  The real question, however, is
whether you can get a large committee to come to a consensus on how to
standardize things.  In the case of sockets, I think that'll be
reasonably easy, for the simple reason that most people do sockets
pretty similarly anyway.  In the case of threads, I think it'll be
substantially more difficult because there are much greater differences
in how threads are implemented, and it'll be much more difficult to
define an API that abstracts away those differences without losing all
hint of control and usefulness.

OTOH, there is fairly strong motivation to standardize them -- I (for
one) would absolutely _love_ to have the committee prove my guess wrong
by managing to do it, but I'm not going to hold my breath for it.

>From a higher-level viewpoint, there's also a fairly simple fact: nearly
any OS can (and most do) support sockets pretty easily.  Supporting
threads in a meaningful fashion is a considerably larger project.  If a
platform doesn't currently include either, adding sockets is likely to
be substantially simpler than adding threads.  Restricting it to
cooperative threads would simplify implementation, but would also render
them nearly useless, at least IMO.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Jerry Coffin wrote:
> In article <aec458c5.0401182320.27bdd9fa@posting.google.com>,
> schnitker@sigma-c.com says...
>
> [ ... threads and sockets ]
>
>> Interestingly, both were included in the early "things we might want to
>> include into the standard library" bullet list used by BS to start the
>> C++0x process. Threads were mentioned as something "we shouldn't make
>> a built-in feature of the language, but make it a(n optional?) part of
>> the standard library, maybe with some bit of language support".
>>
>> I have not yet seen any indication for a change of mind.
>
> Probably not, at least on his part.  The real question, however, is
> whether you can get a large committee to come to a consensus on how to
> standardize things.  In the case of sockets, I think that'll be
> reasonably easy, for the simple reason that most people do sockets
> pretty similarly anyway.

The BSD socket API has been kluged into various operating systems with
varying degrees of change.  It was not that well suited to Unix (it
added another namespace and a whole lot of new functions instead of
extending the file-system) and it is even less well suited to many
other operating systems (what's an FD?).  I think it would take
substantial effort to produce a genuinely generic interface.  select()
would be especially challenging!

> In the case of threads, I think it'll be
> substantially more difficult because there are much greater differences
> in how threads are implemented, and it'll be much more difficult to
> define an API that abstracts away those differences without losing all
> hint of control and usefulness.
>
> OTOH, there is fairly strong motivation to standardize them -- I (for
> one) would absolutely _love_ to have the committee prove my guess wrong
> by managing to do it, but I'm not going to hold my breath for it.

It is not essential to have a thread API, but I believe the language
specification must allow for multiple threads of control and must
specify some basic thread-safety guarantees for multi-threaded
implementations (e.g. multiple threads may read the same container at
the same time).  Thread creation, deletion and synchronisation can be
left as "implementation-specified".  That would at least make it
possible to write generically thread-safe code within the standard.

> From a higher-level viewpoint, there's also a fairly simple fact: nearly
> any OS can (and most do) support sockets pretty easily.  Supporting
> threads in a meaningful fashion is a considerably larger project.  If a
> platform doesn't currently include either, adding sockets is likely to
> be substantially simpler than adding threads.  Restricting it to
> cooperative threads would simplify implementation, but would also render
> them nearly useless, at least IMO.

What if they're optional, as Stroustrup proposes?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <slrnc0q38a.1eg.do-not-spam-benh@tin.bwsint.com>, do-not-
spam-benh@bwsint.com says...

[ ... ]

> The BSD socket API has been kluged into various operating systems with
> varying degrees of change.  It was not that well suited to Unix (it
> added another namespace and a whole lot of new functions instead of
> extending the file-system) and it is even less well suited to many
> other operating systems (what's an FD?).  I think it would take
> substantial effort to produce a genuinely generic interface.  select()
> would be especially challenging!

Well, I'm certainly not trying to trivialize it -- after all, just the
underlying TCP/IP stack isn't something you just whip together in a
spare afternoon.

[ ... ]

> It is not essential to have a thread API, but I believe the language
> specification must allow for multiple threads of control and must
> specify some basic thread-safety guarantees for multi-threaded
> implementations (e.g. multiple threads may read the same container at
> the same time).  Thread creation, deletion and synchronisation can be
> left as "implementation-specified".  That would at least make it
> possible to write generically thread-safe code within the standard.

Sort of.  I think a better option would be to leave creation and
deletion implementation defined, but require at least a few simple
synchronization primitives -- which would end up being (nearly?) NOPs on
a system that only provided single threads.  That would provide the
primitives necessary to write the thread-safe containers, etc., in a
portable fashion, while imposing only the most minimal extra extra for
those who didn't want to really support multi-threading.

[ ... ]

> What if they're optional, as Stroustrup proposes?

That depends on how optional they are.  If their presence is optional,
then it's nearly the worst possible scenario -- the committee has to
spend just as much time and effort on getting them right as if they're
mandatory (and POSIX proved that this is decidedly non-trivial).  At the
same time, all that effort is mostly wasted, because portable code can't
take any advantage of it at all.

Another possibility would be to make them optional for now, but promise
that in the next version of the standard (or some other specified time)
they'd become mandatory.  This is only slightly better, but at least it
gives an assurance that code that uses them will eventually become
portable, and gives vendors real motivation to start working on
providing it.  Overall, not nearly as bad as purely optional, but not
really a whole lot better either.

A third possibility would be to make the _presence_ of the header(s),
functions, etc., all mandatory, but allow thread creation to fail on
systems that don't support multiple threads, and define synchronization
so it can be implemented as (nearly?) NOPs on single-threaded systems.
With some care, this would allow programmers to write code that portably
uses multiple threads on systems that support it, but remains portable
to single-threaded systems as well.

I don't consider any of these truly ideal, but IMO, the last is at least
less bad then the others.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Jerry Coffin wrote:
 > In the case of threads, I think it'll be
> substantially more difficult because there are much greater differences
> in how threads are implemented, and it'll be much more difficult to
> define an API that abstracts away those differences without losing all
> hint of control and usefulness.

But Ada, standardized in 1983, has concurrent programming defined within
the language, and it has stood the test of time. The 1995 upgrade added
some further improvements, and the 0x process may add a few more, but the
basic model is unchanged and works fine on a large variety of platforms.

The secret to success is to concentrate on what the language should be able
to do, not how to bind it to existing implementations. As the simplest
example, any attempt by C++ to address concurrency must specify that the
initialization of a static variable happens exactly once, regardless of how
many concurrent execution streams attempt to access that variable at the
same time. Assuming that the computational model isn't completely lunatic,
binding it to existing threading models will be possible, and possibly easy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]