From -2275358801778308762 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-25 17:12:02 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: Mon, 26 Jan 2004 01:11:59 +0000 (UTC) Organization: TAEUS Lines: 62 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: X-Trace: mail2news.demon.co.uk 1075079519 12399 10.0.0.1 (26 Jan 2004 01:11:59 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Mon, 26 Jan 2004 01:11:59 +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 1AkvIE-0003Dq-00 for mail2news@news.news.demon.net; Mon, 26 Jan 2004 01:11:59 +0000 X-Received: from mulga.cs.mu.OZ.AU (localhost [127.0.0.1]) by mulga.cs.mu.OZ.AU with ESMTP id i0Q1Bul5018553; Mon, 26 Jan 2004 12:11:56 +1100 (EST) X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id i0Q1BudV018544; Mon, 26 Jan 2004 12:11:56 +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 23:58:18 -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-Spamscanner: mailbox1.ucsd.edu (v1.4 Oct 30 2003 22:20:52, 0.0/5.0 2.60) X-MailScanner: PASSED (v1.2.8 359 i0P5wKF6009372 mailbox1.ucsd.edu) 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++:7585 comp.std.c++:979 In article , 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 ]