From -3212599010497571421 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,9a6b7da9ba54eaea X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1993-07-08 15:54:07 PST Newsgroups: comp.std.c++ Path: gmd.de!xlink.net!howland.reston.ans.net!news.ans.net!newsgate.watson.ibm.com!hawnews.watson.ibm.com!charmed.torolab.ibm.com!krk From: krk@charmed.torolab.ibm.com () Subject: Re: C++ Language Extensions Sender: news@hawnews.watson.ibm.com (NNTP News Poster) Message-ID: Date: Thu, 8 Jul 1993 22:26:38 GMT Reply-To: knuttila@vnet.ibm.com Disclaimer: This posting represents the poster's views, not necessarily those of IBM. References: <25937@alice.att.com> Nntp-Posting-Host: charmed.torolab.ibm.com Organization: IBM Lines: 76 In article , rfg@netcom.com (Ronald F. Guilmette) writes: > In article <25937@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) > writes: > > > > > >rfg@netcom.com (Ronald F. Guilmette @ Netcom Online Communications > Services (408-241-9760 login: guest)) writes > > > > > P.S. At this point in time, even if X3J16 totally ignored *all* > suggested > > > extensions (including the ones that Bjarne himeself is ramming... > ummm... > > > I'm sorry... "sheparding" through X3J16) > > > >For the record: I don't ``ram'' extensions through X3J16/ISO-WG. > > Yes. Sorry about that. As chariman of the extensions working group, > you > don't exactly have to. > > (It is interesting to note however that huge and rather poorly defined > hunks > of extension-stuff which were proposed by you, e.g. templates, > exceptions, > namespaces, were adopted, while several trivially small and well > defined > extension proposals have fallen by the wayside.) It is always in the implementation that the truth of a spec is found. Well, we implement this stuff here, so perhaps I can offer a counter opinion. EH has very few holes in its definition. Certainly no major ones. Comparing implementation notes with the HP/USL work has shown a very strong consistency in our implementations. The minor things that have come up will be tidied up at the committee. PT sufferes a bit from other definitional problems in the language that are being cleaned up as the language is being cleaned up. It also suffers from being more closely linked to the compiler environment. It is also, hands down, the most appreciated extension in the community using our compiler. In the end, PT will also be complete, definitionally, because of the number of implementors that will have it in their compilers. This was one reason, of many, for including it in the Working Paper. We haven't implemented 'namespaces' yet, but supposing that it is accepted into the draft, we'll get started. Why? Because our user community has also expressed a need for a solution in this area. That is, of course, the only reason for doing any of this stuff. To reiterate, I think that the extensions that have gone in since the standardization process has started have been improvements. I also think that encouraging implementors to implement the extensions results in complete extensions. Lastly I don't believe that these extensions would be implemented if they weren't in the Working Paper. Certainly not as widely. Its fine to wish for implementations. The only way to get them to happen is vote 'em in. In a world of conformance to standards, it is hard to convince companies to invest in proprietary solutions. > [snip, snip, snip... lots of stuff .... snip, snip, snip] > -- Ronald F. Guilmette ------------------------------------------------------ > ------ domain address: rfg@netcom.com --------------------------------------- > ------ uucp address: ...!uunet!netcom.com!rfg ------------------------------- -- Regards, krk. Kim Knuttila | Do I need to say it?... oh why not C/C++ Architecture | IBM doesn't Speak for Me, I don't Speak for Them, IBM Toronto | but I do Speak for myself... Woof. (416)448-2171