From -71434239551691514 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-24 10:56:36 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!newsfeed1.easynews.com!easynews.com!easynews!feed2.news.rcn.net!feed1.news.rcn.net!rcn!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: Sat, 24 Jan 2004 18:56:35 +0000 (UTC) Organization: TAEUS Lines: 58 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: X-Trace: mail2news.demon.co.uk 1074970595 5014 10.0.0.1 (24 Jan 2004 18:56:35 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Sat, 24 Jan 2004 18:56:35 +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 1AkSxO-0001Ij-00 for mail2news@news.news.demon.net; Sat, 24 Jan 2004 18:56:34 +0000 X-Received: from mulga.cs.mu.OZ.AU (localhost [127.0.0.1]) by mulga.cs.mu.OZ.AU with ESMTP id i0OIuWl5003118; Sun, 25 Jan 2004 05:56:32 +1100 (EST) X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i0OIuW0Y003109; Sun, 25 Jan 2004 05:56:32 +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-NNTP-Posting-Date: Sat, 24 Jan 2004 08:48:46 -0600 X-Newsreader: MicroPlanet Gravity v2.50 X-DMCA-Complaints-To: abuse@adelphia.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 X-Newsgroups: alt.comp.lang.learn.c-c++,comp.std.c++ 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++:7500 comp.std.c++:957 In article , 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 ]