Xref: utzoo comp.object:3607 comp.lang.c++:13689 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!uunet!fernwood!lia!jgro From: jgro@lia (Jeremy Grodberg) Newsgroups: comp.object,comp.lang.c++ Subject: Re: C++ and waitresses (summary, long) Message-ID: <1991May27.032418.2125@lia> Date: 27 May 91 03:24:18 GMT References: <2326@media03.UUCP> Reply-To: jgro@lia.com (Jeremy Grodberg) Lines: 124 In article <2326@media03.UUCP> pkr@media03.UUCP (Peter Kriens) writes: >For example, maybe people can show me a solution >to the following problem > > struct Linked { Linked *next(); }; > struct My {}; > struct MyLinked : public Linked, public My {}; > main() { MyLinked *x; x = (MyLinked*) x->next(); } > (BTW, this compiled with an internal error in Zortech. > it worked with an intermediate, so I guess it is ok?). > >It is a very easy problem, but it forces me to downcast >the next procedure to a MyLinked. I solved this problem with macros, and will be able to solve it with templates when my compiler supports templates. The key is to make Linked a template class which take and returns pointers to whatever class you want. In one implementation I created, there were 2 template classes. The first template class defined an object with pointers to the derived class, and some operations on those pointers, and the second template class made a list of objects of the first template class. Many people complain about how complex C++ is, and how useless or counter-productive C++'s strong type checking and implicit conversion is. For myself, I have found ways to use them that have gone very far in having the compiler validate my code, and have made me much more confident that my code actually works. Yes, I spend a lot of time cleaing up warnings from the compiler, but once I do, I usually have very few bugs. C++ takes time to learn, but so does any object oriented language. Object oriented concepts are hard to learn and use well, because there are a lot of possibilities which serve immediate needs, but few are good for future growth; it takes practice to learn how to make good choices. I think that once the industry gets more collective experience, the complexity of C++ will not be a problem, but rather a bonus. When I learned C, I was glad there were people around to tell me about standard C coding style, and standard ways of doing things, because I didn't have any way to choose among various essentially equivalent options. We have the problem with C++ that there is no standard way. But C++ has only been in widespread use for 1 year, and the language isn't finished yet (with templates and exception handling a must-have on most people's feature list). Now is the time to explore the possibilities of the language, and learn its unique advantages. If you don't want to do that, then you can just write ANSI C with mandatory function prototypes, and compile it under C++, for no added complexity, and no need to use lint. And I also understood >that on certain implementations this might not work at >all because of virtual bases etc. Help.... If I am >right in understanding that this is basically the only >way to do it, then I dont understand the type safety >of C++, if you are forced to bypass it many times, >it does not seem very usefull? > >-- >I also got some questions why I complained about the >const keyword. I tried to explain that though the >concept is stated quite clearly, it seems that once you >start using it, you end up changing a lot of old code >and it propagates fast! If you start afresh I found >it was mostly annoying, just another thing to distract >you from the problem domain. > >--- >One person made a very good comment about extendability: > >> However this messiness is also a strength. When c users needed >> new features, there were a number of techniques that could be used to >> implement needed constructs. I contrast it with Pascal, an elegant >> minimal language. When pieces were found to be missing from Pascal, such as >> string manipulation, it was very hard to add them in. In this country >> C has become a dominant implementation language, and I attribute it to the >> fact that users were able to do things in the language that the original >> designers had never anticipated, whereas a minimal spanning language lacks >> the redundancy that provides for improvisation. > >I completely agree with the fact that a language should >be extendable. But strange enough I found that languages like >C and C++ are definitely not extendable. Both languages have >defined keywords which you definitely cannot change. You >cannot implement your own if or virtual. I found that in >Smalltalk all this is possible because there are no keywords >in the language, just like Prolog. And what I understood from Lisp this >is also the case. So if you talk about extending a language, >then C(++) is definitely not an extendible language. The >usuage is fixed (well as long as Bjarne can keep his >hands of the definition, ehhh.. sorry which definition?). > >---- > >A common remark, to which I agree, is that whatever >I think about it, it will be the dominant language of >the 90's. Somebody wrote: > >> programming. However, I think C++ will become the major language for >> many environments, while alternatives like Eiffel, Objective-C, and >> such will languish in relative obscurity, because of the ease of >> moving to C++ from C and its wide availability. > >I do not agree with the fact that Eiffel and Objective-C >will vanish. There will always be an audience which makes >their choices on performance. If not, the Macintosh would >have vanished long ago. > >One way or the other the industry seems to chose >non-optimal solutions. We got stuck with MS-DOS, Windows >and C++. I will use it, but I will always have a feeling >that it could have been much easier if choices were made >on performance instead of just marketing. > > Peter Kriens > > -- Jeremy Grodberg "Show me a new widget that's bug-free, and I'll show jgro@lia.com you something that's been through several releases."