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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,81cf52699486abe7 X-Google-Attributes: gid103376,public From: Ray Blaak Subject: Re: Ada95 Strengths/Weaknesses. Date: 1999/09/28 Message-ID: #1/1 X-Deja-AN: 530577033 Sender: blaak@ns24.infomatch.bc.ca References: <37EED7B8.245C0054@yukyonline.co.yuky> <7smp30$9aa1@news.cis.okstate.edu> <7sp914$ago$1@nnrp1.deja.com> <7spd4c$9ic2@news.cis.okstate.edu> <7sr7ot$nq9$1@nnrp1.deja.com> X-Trace: news.bctel.net 938580137 207.34.170.88 (Tue, 28 Sep 1999 21:42:17 PDT) NNTP-Posting-Date: Tue, 28 Sep 1999 21:42:17 PDT Newsgroups: comp.lang.ada X-Complaints-To: news@bctel.net Date: 1999-09-28T00:00:00+00:00 List-Id: In article <7spd4c$9ic2@news.cis.okstate.edu>, David Starner wrote: > This has nothing to do with what I was talking about. In C++, I can write > class BigInt, assign integers to it and pass it to templates expecting > numbers. In fact, I can sed s/int/BigInt/g and add include "bigint.h" to the > top of all the files, and the programs will run the same (provided, of > course, that BigInt follows the same semantics as int.) In Ada, I can't write > a template that expects a integer type and pass a BigInt to it. I can't > assign to it from universal integer. In Ada, BigInt can't masquarade as a > number. You might prefer C++'s ability for classes to work directly with integer literals, but Ada's "inability" to do this is not by accident, I believe, but rather result of a philosphical position. In C++, one can implicitly construct objects from any other object for which there is a constructor with the appropriate type as a parameter, e.g., BigInt I = 2; In Ada you cannot. The reason for this is "no implicit conversions". The reason for *that* is "less bugs". Everything you do to change something's type must be explicitly done. This makes all such changes visible in the source code, making what is actually happening easier to understand. It also prevents "accidental" conversions, which can happen quite a bit in C++ if one is not careful. I, in fact, generally prefer to see: BigInt I := CreateBigInt(2); and so usually prefer Ada's restriction. On the other hand, I have been in situations where we did want this implicit conversion, and justified it due to the cost of migrating an object to a new class type. We didn't want to break the mountains of old code, so with the appropriate constructor, a previously exposed raw information string was now implicitly converted into an appropriately encapsulated object. After a suitable migration period, we can remove the constructor, after which compiler errors will quickly point out the (hopefully) few remaining migrations needed. One of the great things about C++ is that you can control this. Don't supply the constructors, and the implicit conversions won't happen. In general, C++ done right can be just as correct as Ada. It is just that it is so easy to be lazy. If one does want to have Ada source looking closer to implicit conversions of literals, supply an appropriate definition of the unary "+" (as suggested elsewhere by Robert Dewar): function "+" (i : Integer) return BigInt; BigInt I := +2; -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, blaak@infomatch.com The Rhythm has my soul.