From 2457128139011480842 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,9a6b7da9ba54eaea X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1993-08-05 16:54:50 PST Newsgroups: comp.std.c++ Path: gmd.de!xlink.net!sol.ctr.columbia.edu!usc!cs.utexas.edu!swrinde!news.dell.com!tadpole.com!uunet!newsgate.watson.ibm.com!yktnews.watson.ibm.com!hawnews.watson.ibm.com!charmed.torolab.ibm.com!krk From: krk@charmed.torolab.ibm.com (Kim Knuttila) Subject: Re: C++ Language Extensions Sender: news@hawnews.watson.ibm.com (NNTP News Poster) Message-ID: Date: Thu, 5 Aug 1993 22:30:05 GMT Reply-To: knuttila@vnet.ibm.com Disclaimer: This posting represents the poster's views, not necessarily those of IBM. References: Nntp-Posting-Host: charmed.torolab.ibm.com Organization: IBM Lines: 94 In article , rfg@netcom.com (Ronald F. Guilmette) writes: > >In article > >krk@charmed.torolab.ibm.com () writes: > > > >|> 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. > > That you have managed to find anyway... :-) > > Just be patient and wait until users get ahold of this stuff and > start > seriously banging on it! > I am patient. Users have had my product well over a year externally. We have a large internal user community that have had it even longer. By all accounts, they are 'banging on it'. I stand by my comment. > > >|> Comparing > >|> implementation notes with the HP/USL work has shown a very strong > consistency > >|> in our implementations. > > Great. So you both made the same mistakes in the same ways, yes? I guess that's one way to look at it... > > Is this supposed to be comforting? Is it offered as proof that the current > definition of exception handling is really fully cooked? (Sorry. I'm not > convinced.) > Really? Jeez, I'm sorry. Help me understand your concern with regards to EH. For my part, I'll certainly try to include any points you have in the finished standard. [snip, snip, snip] > > >|>In a world of conformance to standards, > >|> it is hard to convince companies to invest in proprietary solutions. > > Nonsense. Just TRY to find ANY compiler vendor than hasn't implemented > his/her own specialized extensions (where they saw a need) already. Good > luck. In a world of conformance to standards, implementors try their best > to conform AND to provide their own pet extensions (often as a way of > helping to lock-in their respective customer bases... a technique which > IBM employees should be familiar with, as IBM practically invented the > concept of customer lock-in). > BWAHAHAHAHA... I love this one:-) Thanks for the day brightener! > In short, compiler vendors DO invest in proprietary solutions, and often, > so do their customers. Why do you think that languages like FORTRAN and > COBOL have undergone several separate standardizations? And where did > you think the innovations which went into the later revisions of those > language standards came from? They came from independent innovations > (i.e. "extensions") BEYOND the earlier standards, which were implemented > by implementors and then used and requested (frequently) by users. > > That's actually not a bad way to standardize new features. Let them soak > awhile. Let them prove themselves in widespread practice. THEN put them > in a standard. > I stand by my original post. I work in a C/C++ compiler shop. We simply do not invest in proprietary solutions unless we must. Even then, it's small stuff, or stuff not yet addressed by the standards group that needs a solution now. It is much preferrable to me to have the current situation than to try to merge multiple vendor solutions for something as large as, say, EH. > -- > > -- 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 | I don't even Speak for Jake, (416)448-2171 | but I do Speak for myself... Woof.