problems/risks due to programming language

[Jim ADCOCK]

In article <259 at eiffel.UUCP> bertrand at 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.]