From 8138087864461532068 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-23 07:43:57 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!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?) Date: 23 Sep 1994 13:58:15 GMT Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle Perceptive) Lines: 69 Message-ID: References: Reply-To: tmb@idiap.ch NNTP-Posting-Host: arolla.idiap.ch In-reply-to: dfs@doe.carleton.ca's message of Thu, 22 Sep 1994 15:09:31 GMT Xref: bga.com comp.std.c++:4525 comp.lang.c++:30193 In article dfs@doe.carleton.ca (David F. Skoll) writes: |The biggest problem (as I see it) with C++ is its schizophrenic desire |to be a new language on the one hand, and largely compatible with C on |the other hand. I believe that it's time to drop compatibility with C |to clean up the language. For example, changing C++ arrays to more |than the C concept would help a lot. Getting rid of unions would |vastly simplify the implementation of a garbage collector (and unions |aren't really needed when inheritance is available.) But there is no reason to throw the baby out with the bathwater. We can migrate gradually to these new constructs. For example, we don't have to get rid of C-style arrays just to have safe arrays. They can live side-by-side. Likewise, we don't have to get rid of C-style unions to support garbage collection. |When I mentioned "special rules", I refer to the ARM -- for example, |see the table on page 306, which defines 15 types of constructors, |destructors, conversion functions, operator functions, friend |functions and other member functions, and describes whether or not |they are inherited, can be virtual, can have a return type, can be a |member or friend and are generated by default. This, IMO, is |egregious. It's terrible to force software developers to remember or |refer to this table. There must be a cleaner way. Well, some of these problems would go away with some of the extensions I mentioned above. For example, many kinds of constructors, assignment operators, and destructors would not be for most code under the Ellis and Detlefs' safe C++ proposal. |Well, maybe. I've written a fairly large system in Lisp, and am |writing one in C++. There's no doubt that C++ is more efficient than |Lisp in terms of run-time, but I have grave doubts that it's more |efficient in programmer-time. I agree: C++ is probably not more efficient in terms of programmer time. |Absolutely. One of my gripes with C++ is the amount of detail. The |ARM describes a baroque language with thousands of minutiae which |certainly bedevil someone learning the language (and, I'd bet, |experienced programmers too.) By making the language more regular through extensions, most people won't have to remember most of those features. |> -- 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 | |Yes, but in the effort to maintain backward-compatibility, all of |these things would still have to be available, making compiler-writing |a bit of a nightmare. C++ compiler writing is already a nightmare. And the Ellis and Detlefs proposal is not all that hard to implement. |> Anther area in which C++ is a real mess is in templates. | |Yes. For my project, I have made the heretical decision not to use |templates at all. Well, it depends on what performance tradeoffs you are able to make for your application. But for some applications, templates are indispensable, messy as they are. THomas.