From 3902664159730922377 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,9a6b7da9ba54eaea X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1993-07-19 15:17:14 PST Newsgroups: comp.std.c++ Path: gmd.de!xlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!news.ans.net!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: Mon, 19 Jul 1993 21:17:44 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: 131 In article , kanze@us-es.sel.de (James Kanze) 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. > 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. > > I suppose EH is exception handling. Yep. Sorry for dribbling off into acrynonym land. > > |> 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. > > From the context of the previous posting, PT is templates? Yep again. PT == Parameterized Types. > > |> 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. > > I don't think the problem has been with the quality of the individual > extensions (although I personally have some doubts concerning > namespaces). But that is the issue to which I was responding... > The problem is the trade-off, extensions *or* a standard > anytime soon. My guess is that each of the aforementioned extensions > have delayed or will delay the standard by about a year. (Maybe a bit > less for exceptions, certainly more for templates.) Well, I don't know if I buy the estimate. How did you come up with it? If we had accepted no extensions (which as Andy pointed out earlier was not possible in our charter), I'm not sure we would be done noticeably quicker. > > My customers are beginning to shy away from C++, because they ask > themselves: "if the experts on the C++ committee don't understand the > language well enough to be able to define it, how can we expect our > programmers to be able to write portable programs in it?" Now I know > enough about C++ *and* the current standards effort to know 1) you can > write relatively portable programs with the language just as it > stands, standard or no, and 2) most of the extensions *are* an > improvement, and address important issues. But there is a perception > problem here. One of the more frequent criticisms of C++ is that it > is overly complex. By continually delaying the standard, we add to > the effectiveness of this arguement. Firstly, I doubt that concerns regarding C++ 'complexity' will be alleviated by the appearance of a standard. People using this argument are usually referring to properties of the language, and the properties referred to are not likely to disappear. Secondly, standards last a long time. We are in that uncomfortable zone between the establishment of a defacto standard, and the issue of the first standard for the language. This is not really the best time to be in a hurry. Sure, timing is a factor, but it is one of several. Of course, your customers are right to assess the risks and rewards of the paths available to them. If they believe the best balance is for another standard programming language, it is their business to make the choice. Programming in C++ today is probably analagous to programming in C in 1987. Most people's code was not broken by the C standard, but some was. Some breakage was avoidable by keeping track of the C standardization activity. So... keep track of the C++ committee, and keep an eye on your vendor. And if you have specific concerns, voice them. Use your vendor, or this forum, or even direct mail to the committee. We all want this to work. > -- > James Kanze email: kanze@us-es.sel.de > GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France > Conseils en informatique industrielle -- > -- Beratung in industrieller Datenverarbeitung -- 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.