Re: Bye-bye Ada ? (Ada95 Wholesale Changes?)

[slatyb@yahoo.com (K)]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:<3E42A61C.20905@cogeco.ca>...
> But I can speak for my own experience, that in
> largish C++ projects, I always spent an incredible amount of
> time looking in core files and working with a debugger to
> find out why some "strange behaviour" was happening in
> those C++ projects. Sometimes it was related to those
> automatic type promotions, and at other times, it was
> related to memory corruption problems of one sort or
> another (and it need not even be your own code! Sometimes
> C++ library code does this to you).

Ada library code doesn't do this to you because there is none.
But any Ada code that uses new/unchecked_deallocation has the
potential
to corrupt the heap.

> 
> On top of all this, once you get your large C++ application
> to actually work, you then want to "port it" to another
> platform, with sometimes a different compiler (or even
> a different/updated gcc compiler). What do you find?

Why not just port to the same version of gcc?

> 
>    - Changed behavior in automatic type promotion, leading
>      to changed application behavior
>    - #include file problems
>    - C++ library incompatibilities/limitations

I'm guessing that you only use a single Ada compiler, GNAT.
The Ada standard is a few years older than the C++ standard,
so there is less change between compiler versions.
Gcc has tried to track the C++ standard as it evolved from draft
to draft, so naturally there have been language changes from 
version to version.  And every system vendor provides a licensed
C++ compiler, and they have converged on the standard at different
rates.  The obvious solution is to do the same thing you have done
with Ada: build the same version of gcc on every platform.

> 
> Sure you can say that this occurs due to poor planning,
> or design. But the Ada point is that this is not checked,
> nor enforced up front by your tools.  My hobby time is
> time I hate wasting this way ;-)
> 
> In smallish projects, Ada sometimes takes me longer. This
> is usually due to library issues and bindings.
> 
> The payoff is huge though (for me) in largish projects. In
> the last 4 years (I think) of using Ada (since my conversion ;),
> I've only encountered memory corruption once (I had freed
> an object twice due a logic/design error).  The rest of
> my time is "quality time with the compiler", learning how
> to avoid certain design errors, and learning how to better
> engineer modules so that the dependencies are pure and
> correct (C++'s elaboration is pale by comparison). My
> debugging time is 25% or less of the C++ debugging time.
> (This gives me a much more pleasant use of my hobby time).
> 
> When I debug, it is because I am finding out why _I_ made
> some logic error. It is not due to corruption, or some
> faulty elaboration order; not due to external memory
> references that the linker decided were the same (name
> collision), not due to #include file sequence, not due
> to automatic type promotion surprises etc.
> 
> SUMMARY:
> 
> I don't agree with your statement for large projects.
> 
> 
> > You're probably right about the level of C++ code around.
> > It's easy to bludgeon C++ code into submission when it
> > won't compile, instead of understanding what is wrong.
> 
> I also believe that inexperienced programmers can produce
> better code in Ada95. 

Their code may be less prone to crash, but it also is 
less featureful because they have relatively few libraries
to draw upon, and none have a large user base.

> You won't get the same from them
> in C++, even if they can wrap their head around the existing
> code they must read and customize.
> 
> But then, this is just my opinion on the subject.
> 
> 
> DON'T TRY THIS AT HOME 8-)
> 
> Ada programmers may wince at this, but here is something that
> I find really useful about Ada95 for my own Open
> Source development:
> 
> If I look at a spec of a package I want to "clean up", and
> I don't like the way the data type is presented, and want
> to make some sort of wholesale change to the package, I'll
> first make the necessary tweaks or major changes to the
> specs. This may include:
> 
>   - Changing constants to enumerated types / vice versa
>   - Changing a weak type to a strong type
>   - Making types more range specified (subtypes)
>   - Changing function/procedure API changes
>   - Change a record/tagged type (class) to the other kind
>   etc.
> 
> Then I jump into emacs, and start invoking "make" and let
> the compiler tell me about all of those new errors that will
> now spew of the compiler. Using emacs I jump to the source
> of the error (using emacs macros) and make all the necessary
> changes, until the errors go away. With Ada95 this has
> never failed me, though I expect some little case may
> bite me some day, doing changes like this.
> 
> THIS HAS NEVER WORKED WELL FOR C++. 

It works very well for me.  It even works on the fairly large body of
commercial code that I am currently maintaining.  
Recently I needed to delete a business rule, and I started by deleting
an argument from the declaration of the function that enforced the
rule.
Then I just fixed compile errors recursively until there were no more.

> C++ would never identify
> all of the necessary changes, because of the number of
> "automatic conversions" and so on.  C++ never tells you
> that you have a missing case in a switch statement, and
> its very forgiving mixing enumerated types with ints etc.

You can convert enumerated types to int, but can not
convert ints to enumerated types.  Even the first conversion
could be unfortunate if one wanted to change an argument type
from an enumeration to int.  However, I prefer to wrap enumerations
in a typesafe template class.  But switch statements are much safer
in Ada.  I avoid them in C++ because it's too easy to miss one.

> C++ will not tell you when a related constant or #define
> needs to be updated.

Nor will Ada, nor any other language.  If you declare
x = 17, and y = 289, no compiler will divine
that y should be equal to x*x.  But it's certainly
possible in C++ to define the y in terms of x.
This sounds like a comparison of correct Ada practice with
poor C++ practice.

With templates, you can even compute functions
of integer constants at compile time:
    const int x = 8;
    const int y = Factorial<x>::value;