From -6973421888017012571 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,b2ee37ea6b4e52ab X-Google-Attributes: gidf78e5,public From: James.Kanze@dresdner-bank.com Subject: Re: ISO vs ANSI C++ Date: 1999/07/15 Message-ID: <7ml0ep$jlq$1@nnrp1.deja.com>#1/1 X-Deja-AN: 501383972 X-NNTP-Posting-Host: 193.194.7.84 Approved: stephen.clamage@sun.com (comp.std.c++) References: <7m5mhs$ib0$1@gxsn.com> <3788dece.3064835@nntp.netcom.ca> <7mitn0$dch@library2.airnews.net> X-UID: 0000000001 X-Status: $$$T X-Http-User-Agent: Mozilla/4.6 [en] (WinNT; I) X-Http-Proxy: 1.0 x41.deja.com:80 (Squid/1.1.22) for client 193.194.7.84 Organization: Deja.com - Share what you know. Learn what you don't. X-Article-Creation-Date: Thu Jul 15 15:58:25 1999 GMT X-MyDeja-Info: XMYDJUIDkanze Newsgroups: comp.std.c++ Originator: clamage@taumet In article <7mitn0$dch@library2.airnews.net>, "Bill Wade" wrote: > Herb Sutter wrote in message <3788dece.3064835@nntp.netcom.ca>... > > > >Of course, the committee is still doing some work: > > > >We specifically cannot sneak in new features by calling them defects > >(e.g., no one can say "oh, the library doesn't have a hash-based map > >[or, garbage collection; or, a GUI library], I consider that a defect!" > >to sneak in a new feature). Not to say that it hasn't been tried; it > >just isn't accepted. :-) > It is arguable that the committee is doing what it "specifically cannot." > Promising that vectors will be contiguous seems to be a feature (and > codifies existing practice for all commercial implementations). I'll agree > that this is arguable. If notables such as BS were writing that vector was > contiguous they probably thought that was what the standard said and it is a > defect if it wasn't what the standard said. > Removing the vector specialization, which may happen, is clearly a > case of trading one set of well-understood features (my vector of 1e8 > elements fits easily in main memory on my platform) for another set of > well-understood features (vector remains a Container, and performance > for some access patterns improves). I think the real question is who enforces the rule. If the committee itself is in charge of enforcement, they could sneak in anything they wanted. (I don't think they would -- I think they take the rules seriously. But potentially, they could.) If ISO enforces the rules, I suspect that there are real corrections that won't be allowed. Your example of vector is one case: requiring the array to be continuous doesn't change any behavior, and in practice, it doesn't change any implementations, either. As such, and given the comments of people like Stroustrup, I'd be inclined to consider it a (minor) correction. Would ISO, though, looking at only the words in the voted upon standard? Another example that came up recently: the thousands separators in num_put. Again, given the comments of the author, and what seems reasonable, I'd be willing to accept this as a correction. However, it *does* change the behavior of user programs, compared to the text that currently is there (although I'm willing to bet that the number of user programs actually changed is 0). And it would require a change in at least one implementation. Would ISO accept this? -- James Kanze mailto: James.Kanze@dresdner-bank.com Conseils en informatique orient�e objet/ Beratung in objekt orientierter Datenverarbeitung Ziegelh�ttenweg 17a, 60598 Frankfurt, Germany Tel. +49 (069) 63 19 86 27 Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't. [ 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://reality.sgi.com/austern_mti/std-c++/faq.html ]