From -7945777978708527353 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,299b13f3264fa537 X-Google-Attributes: gidf78e5,public X-Google-Thread: 114592,1b9fa508fe1b725 X-Google-Attributes: gid114592,public X-Google-ArrivalTime: 2004-01-21 18:21:23 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: jcoffin@taeus.com (Jerry Coffin) Newsgroups: alt.comp.lang.learn.c-c++,comp.std.c++ Subject: Re: using boost::any Date: Thu, 22 Jan 2004 02:21:16 +0000 (UTC) Organization: TAEUS Lines: 77 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: X-Trace: mail2news.demon.co.uk 1074738076 21816 10.0.0.1 (22 Jan 2004 02:21:16 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 22 Jan 2004 02:21:16 +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 1AjUT5-0005fj-00 for mail2news@news.news.demon.net; Thu, 22 Jan 2004 02:21:15 +0000 X-Received: from mulga.cs.mu.OZ.AU (localhost [127.0.0.1]) by mulga.cs.mu.OZ.AU with ESMTP id i0M2L9l5019549; Thu, 22 Jan 2004 13:21:12 +1100 (EST) X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i0M2L8Dg019539; Thu, 22 Jan 2004 13:21:08 +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-Newsreader: MicroPlanet Gravity v2.50 X-NNTP-Posting-Date: Wed, 21 Jan 2004 00:31:22 EST X-Spam-Level: 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++:7350 comp.std.c++:906 In article , 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 ]