Xref: utzoo comp.software-eng:3112 comp.lang.c:26701 comp.lang.misc:4373 Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.software-eng,comp.lang.c,comp.lang.misc Subject: Re: problems/risks due to programming language Message-ID: <53012@microsoft.UUCP> Date: 8 Mar 90 21:08:51 GMT References: <6960@internal.Apple.COM> <259@eiffel.UUCP> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 103 In article <259@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes: [Not totally without cause, IMHO] > How can the words ``strong type checking'' be applied to a language >in which any variable may be cast to any type? How can the words 'strong type checking' be applied to a language that gets its permissions on return types exactly backasswards? Fix your *own* language, before throwing stones, Bertrand! In C++ not any variable can be cast to any type, although many questionable casts are allowed *if specifically called for by the programmer* In this light C++ follows the C lead of assuming the programmer is a mature adult who can make his/her own decisions on these things. Other languages don't *really* prohibit programmers from doing these things where the programmer desires -- if worse comes to worse, the programmer just breaks out the old assembly language, and does what is necessary to get the job done. A problem C++ has is that the C++ community has a large number of old C hackers who run fast and loose with their coercions, and then find that in C++ these hacks tend to bite them. But, at least C++ *has* this large community of old C hackers. [Not to use the term "hacker" in a totally derogatory sense] The biggest problem [IMHO] is the continued heavy dependence by many C++ programmers/implementations on the C Pre Processor -- which allows for textual substitutions to text code before the code even gets to the C++ compiler. Not only is the C Pre Processor totally *not* type safe, it also allows programmer to make all kinds of hacks to the [apparent] syntax of their code. Further, the C Pre- Processor makes simple tasks, such as the correct importing/exporting of definitions a real nuisance. >In which you declare the type of a generic list element to be >``pointer to characters''? C++ provides "C" primitives like "pointer to char" that programmers can use to create their own well encapsulated higher-level classes such as "String." Other OOPL languages, such as Eiffel, do not provide this low level support. Instead, the authors of these other languages break out their handy-dandy "C" compiler and program up *one* version of a "String" class that *all* users of the language must use -- even if it doesn't make the optimal speed/space/complexity tradeoffs for that a particular user needs. This heavy dependence on standard libraries to do everything tends to mean that OOPLs taking this approach only come from one vendor. Better to provide compilers and libraries separately, and allow users to choose which from where best meet their needs. C++ attempts to provide the power and flexibility to cover the entire spectrum of programming tasks users need to do. This includes the power and flexibility to hose yourself, if you insist on doing so. > C++ only magnifies the problems of C, and it does not even have the >excuses that can be invoked in the case of a 20-year old design such as C. I am somewhat sympathetic to this complaint. The latest definitions of C++ try to be backwardly compatible with K&R C, ANSI-C, and previous versions of C++. In some areas, this makes for some pretty complicated language rules. This makes the life of compiler writers harder, so that users can write C/C++ code as they are use to writing, and most of the time their software will compile without compiler squawks. Personally, I think it would be good to give up some of the backward compatibility in order to clean up some of the language rules. Perhaps this will happen as part of the ANSI-C++ standardization effort. In any case, it will be nice to have a standardize OOP language. >All the flaws of the older language are still there; amount countless >examples, the break and switch instructions, which were purportedly >responsible for the AT&T breakdown (and started this whole discussion) >are still there exactly as in C. The bug would have occurred identically. C++ OOP programmers avoid switch statements as not being "object oriented," so propagating this "C" bogosity to C++ is not much of a problem. Compilers can choose to warn against missing break statement, if the compiler writers so choose. Better yet, an OOPL compiler should warn against using switch statements in the first place! > Then there are new complexities and major new trouble spots - >such as default static binding, which means the guarantee that the >*incorrect* version of an operation will be applied! I disagree. If a programmer wants a member function to answer to a particular abstract protocol, the programmer creates such an abstract protocol, marking its member functions "virtual", and inherits the protocol in concrete classes matching that protocol. Member functions in those concrete classes that match the abstract protocol are automatically default dynamic binding. The "default static binding" you mention keeps classes with method names that *accidentally* match the names of parts of protocols from being considered such. This prevents the problem common in other OOPLs where method names accidentally match, causing problems not detected [if ever] until run time. As always, the proof is in the pudding. I encourage people new to OOP to actually *try* several languages in "non-trivial" tasks, and see how well those languages, and their compilers, meet you needs. Your smilage will vary. [Standard disclaimer, these are *my* opinions only. I do not disagree with Bertrand entirely, only in degree.]