Re: why learn C?

[Georg Bauhaus <bauhaus@futureapps.de>]

On Thu, 2007-03-29 at 17:51 -0700, kevin cline wrote:
> On Mar 20, 12:37 pm, <adawo...@sbcglobal.net> wrote:
> > "Marc Boyer" <Marc.Bo...@enseeiht.yahoo.fr.invalid> wrote in message >
> >
> > It has always seemed rather odd to me that people who are as intelligent
> > as programmers, rarely question the silliness of using tools such as C
> > and C++ for serious work.
> > They simply take for granted that the kind
> > of errors that are so common in those languages are somehow akin to
> > the laws of nature.
> 
> No, what actually happened is that expert C++ developers learned to
> use C++ in such a way that those errors can not happen.  While it is
> possible to write unsafe code in C++, it is also possible to adopt
> coding guidelines that makes it easy to find and eliminate unsafe
> code, and for most applications, that's quite good enough.  One reason
> that experts choose C++ over Ada for performance-critical applications
> because C++ templates allow compile-time type safety in high-level
> code in a way that Ada generics do not.


Nevertheless, adherence to tradition and culture group preferences
(for lack of a better word) seems to prevent several highly desirable
additions or changes to C++ (and D. And Ada.). Or their integration
with the very templates that turn out to achieve useful effects:
A well defined and expressive base type system; case coverage in
conditionals; simplified overload rules (why overloading in
the first place when we have powerful templates and virtual
functions?); normal treatment of the return parameter in type
checking; ...

For example, why is int not a template? Sure it is possible to
come up with a number of templates and have the compiler answer
the question whether an all C++ program is base type safe.
So why not make int less C-ish?
And throw out types whose existence can no longer be justified,
at higher or lower level, such as short, long, and long long:

   class Coordinate : int<0, 4096, unsigned>, Ring {
     // ...
   };

I'm not saying that these things can't be programmed in C++.
I'm saying that they must be programmed if you want them in C++.
That's the point.

(Likewise, Ada should have the elementary school types only on
request, i.e. no predefined "Integer" with all the operations
some of which are hardly ever used in an average program.
(Only average programs should affect what's in a language,
no?)

Do we profit considerably from the presence of and, in cases, need
for all of typedef *and* class *and* struct *and* typename? And
a guaranteed load of rules per project?
The language's historic complexities can still provide for
entertaining distractions from solving the problem. C++ is not
alone here, but strangely, some programmers seem to insist on
old baggage even in new programs.

Template programming is tricky and likely will be because
templates weren't designed for using them in the useful ways
which we learn now many years after their addition to the
language. They are a quite interesting experimental feature of
compiling technology. (If they were not, I'm sure investors would
have asked for a different design. One that has less potential of
affecting programmer performance in *both* directions.
The work needed to understand or improve template error messages
is considerable: programmers need expensive time to fix template
mistakes. Witness the opportunity for tool shops to
sell expert systems for the interpretations of template error
messages, and all the work that goes into improving them somewhere
in the tool chain.)