From -5866293970217595713 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,d733139e7969f81d X-Google-Attributes: gid109fba,public X-Google-Thread: f78e5,d733139e7969f81d X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1994-09-22 09:06:06 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!spool.mu.edu!bloom-beacon.mit.edu!ai-lab!life.ai.mit.edu!tmb From: tmb@arolla.idiap.ch (Thomas M. Breuel) Newsgroups: comp.std.c++,comp.lang.c++ Subject: Re: How relevant is ANSI C++? (Re: Is STL a good standard?) Followup-To: comp.std.c++,comp.lang.c++ Date: 22 Sep 1994 08:38:18 GMT Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle Perceptive) Lines: 101 Message-ID: References: Reply-To: tmb@idiap.ch NNTP-Posting-Host: arolla.idiap.ch In-reply-to: dfs@doe.carleton.ca's message of Wed, 21 Sep 1994 19:50:09 GMT Xref: bga.com comp.std.c++:4487 comp.lang.c++:30031 In article dfs@doe.carleton.ca (David F. Skoll) writes: |In article , Thomas M. Breuel |(tmb@arolla.idiap.ch) wrote: | |> In fact, |> many people (including some on the ANSI committee, apparently) are |> hoping that additional functionality will become de-facto |> standardized, like | |> -- garbage collection |> -- threads and tasking |> -- runtime error checking |> -- closures [with dynamic extent] |> -- dynamic typing (not just type identification) |> -- signatures |> -- sound replacements for cpp functionality | |This will make C++ change from an unruly proliferating hack stuck |awkwardly on top of C into an absolutely incomprehensible tangle of |messy syntax and special rules. No, it will make C++ into a language that's easier to use and cheaper to develop code in. It will make C++ less of a "proliferating hack" and less "awkward". The only of these extensions that requires new syntax and new rules is replacements for cpp functionality. The others don't require new syntax or new rules (well, OK, signatures require one keyword with syntax like "sizeof"); they either can be implemented completely with a library-like interface (GC, threads, dynamic typing, runtime error checking) or they simply relax a haphazard constraint on current syntax (nested function definitions). In fact, such features are already in use in a number of implementations. Several of them have been proposed by Stroustrup himself. |If you want GC, closures, dynamic |typing, etc, why not use Lisp or Scheme or some other language |designed for it from the start? C++ is a language that encourages efficient implementations and is backwards compatible and highly interoperable. Those are features that neither Lisp nor Scheme offer. Those are properties won't be affected at all by the above additions. Also, the devil is in the detail. C++ dynamic typing and C++ closures aren't anything like Lisp or Scheme dynamic typing. Signatures are a style of programming that doesn't even exist in most other statically OOLs. In fact, the incomprehensible tangle that C++ already is is due in part to the absence of some of these features. Adding them considerably simplifies the language for most users: -- lack of garbage collection means that all users have to face issues such as temporaries, constructor/ destructor semantics, etc.; in the presence of GC, these would be something most people wouldn't have to think about -- lack of signatures implies the need for MI with all its complications in implementation and semantics; with signatures, MI could be ignored by most users and might eventually even become obsolete (replaced by a simple multiple implementation inheritance scheme) -- lack of dynamic typing makes binary I/O unsafe and cumbersome ("dynamic typing" in C++ also mean determining object structure statically in templates with no associated runtime overhead) -- lack of closures makes it necessary to abstract implementation via cursor classes; cursor classes require the class author to make the state of an iteration explicit, and they are not even particularly easy to use -- lack of sound cpp-like constructs makes developing better programming support tools really difficult (and if you want messy semantics, you can't get any "better" than a mix of cpp and C++) -- lack of garbage collection makes exceptions much more difficult to use in practice Anther area in which C++ is a real mess is in templates. I'm not sure whether there is a good way of fixing that, though. The problems seem mainly related to the way overloading is resolved for type parameters, and to the bizarre scoping rules for class scope. Unfortunately, the choices that C++ made here seem rather deeply ingrained with the general approach C++ has to doing things. So rather than rejecting these features just by their names and their association with Lisp, I suggest you evaluate these issues carefully and from a technical point of view; there have been several papers describing the extensions--look them up and make specific criticism. In fact, even among many people that opposed the inclusion of the above features in the standard, many of them seem to agree that they are fundamentally useful and important. Standards committees rarely make choices only based on technical merit. Thomas.