From 7297882099364840336 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 114592,1b9fa508fe1b725 X-Google-Attributes: gid114592,public X-Google-Thread: f78e5,299b13f3264fa537 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2004-01-23 15:20:48 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!chcgil2-snh1.gtei.net!news.bbnplanet.com!nycmny1-snf1.gtei.net!news.gtei.net!colt.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: schnitker@sigma-c.com (Uwe Schnitker) Newsgroups: alt.comp.lang.learn.c-c++,comp.std.c++ Subject: Re: using boost::any Date: Fri, 23 Jan 2004 23:20:46 +0000 (UTC) Organization: http://groups.google.com Lines: 86 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: mail2news.demon.co.uk 1074900046 687 10.0.0.1 (23 Jan 2004 23:20:46 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Fri, 23 Jan 2004 23:20:46 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.12) id 1AkAbV-0000Aw-00 for mail2news@news.news.demon.net; Fri, 23 Jan 2004 23:20:45 +0000 X-Received: from mulga.cs.mu.OZ.AU (localhost [127.0.0.1]) by mulga.cs.mu.OZ.AU with ESMTP id i0NNKVl5013594; Sat, 24 Jan 2004 10:20:31 +1100 (EST) X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i0NNKV40013585; Sat, 24 Jan 2004 10:20:31 +1100 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ucar.edu X-Newsgroups: alt.comp.lang.learn.c-c++,comp.std.c++ X-NNTP-Posting-Date: Thu, 22 Jan 2004 12:08:28 +0000 (UTC) X-Spamscanner: mailbox1.ucsd.edu (v1.4 Oct 30 2003 22:20:52, 0.0/5.0 2.60) X-MailScanner: PASSED (v1.2.8 56769 i0MC8T6n068548 mailbox1.ucsd.edu) X-Spam-Status: No, hits=0.0 required=5.2 tests=none autolearn=no version=2.60-mulga_r1 X-Spam-Checker-Version: SpamAssassin 2.60-mulga_r1 (1.212-2003-09-23-exp) on mulga.cs.mu.OZ.AU Xref: archiver1.google.com alt.comp.lang.learn.c-c++:7472 comp.std.c++:936 jcoffin@taeus.com (Jerry Coffin) wrote in message news:... > In article , 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 ]