From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3a9b49a9162025eb X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-06 23:17:58 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: slatyb@yahoo.com (K) Newsgroups: comp.lang.ada Subject: Re: Bye-bye Ada ? (Ada95 Wholesale Changes?) Date: 6 Feb 2003 23:17:58 -0800 Organization: http://groups.google.com/ Message-ID: <4c2ec8a8.0302062317.18a3a361@posting.google.com> References: <3E3B7BB5.A1A070@adaworks.com> <3NY_9.9226$x63.6255@nwrddc01.gnilink.net> <3E40A07A.CD174746@adaworks.com> <1044457651.769640@master.nyc.kbcfp.com> <3E42A61C.20905@cogeco.ca> NNTP-Posting-Host: 24.219.89.90 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1044602278 15582 127.0.0.1 (7 Feb 2003 07:17:58 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 7 Feb 2003 07:17:58 GMT Xref: archiver1.google.com comp.lang.ada:33866 Date: 2003-02-07T07:17:58+00:00 List-Id: "Warren W. Gay VE3WWG" 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::value;