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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Running a preprocessor from GPS? Date: Fri, 31 Jul 2015 08:29:43 +0200 Organization: cbb software GmbH Message-ID: References: <2df4698f-4c8e-457c-822d-209cb2f8ab5e@googlegroups.com> <014427b1-ff7a-4a69-82e6-0330af77ed96@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: ChlmA4XFxcJoDoqGdDSflw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:27251 Date: 2015-07-31T08:29:43+02:00 List-Id: On Thu, 30 Jul 2015 19:23:18 -0500, Randy Brukardt wrote: > "EGarrulo" wrote in message > news:d3142cab-776d-4daa-8475-1dd4d46d8556@googlegroups.com... >> On Thursday, July 30, 2015 at 9:32:17 PM UTC+2, Randy Brukardt wrote: > ... >>> And there couldn't be any useful runtime checking, either >> >> Why not? Please explain me why this is acceptable: >> >> -- This conversion will fail if Some_Integer is bigger than what >> -- Constrained_Integer_Type can hold. >> Some_Constrained_Integer := Constrained_Integer_Type (Some_Integer); >> >> whilst this is not: >> >> -- This conversion will fail if Any doesn't contain an Integer. >> Some_Integer := Integer (Any); >> >> I don't see any difference. Both conversions can fail at runtime because >> types >> don't match. > > This is the same nonsense that Dmitry has been spouting. In the first > instance, you have the *same* types with different constraints (ranges in > this case). Ranges *might* be checked at rumtime, although Ada compilers > spend an enormous amount of effort into checking them at compile-time (so > there is no overhead). It is nowhere same what I am saying. [Leaving apart the point that subtype is a type and it is not same, the semantics of operations is different.] > The second case is a mapping of actual different types. That would require > some sort of runtime type representation, which would imply a lot of > overhead for elementary types (as the runtime type representation would be > larger than the type itself in many cases). No. The actual problem is that Any does not have the operation "Integer". It is all about semantics. Type conversion is an operation as any other [I don't care what RM says, when semantics is considered, you know]. There is no such operation between any type and Integer. Period. What you are talking about is some imaginary scenario when there existed Root_Integer'Class and Any would be from that class. Then, indeed, Integer would a primitive operation of. But in that scenario no conversion will be ever necessary anyway, because Put (or Image) would be just another operation of. In short, you don't need to convert anything if you have a class. That is the beauty of strong typing and Ada's OO model. It is safe and you don't need type conversions. All cases where you do are suspicious. > Additionally, elementary types > are by-copy; that would prevent the techniques used for tagged types from > working. It would not, the class-wide of a scalar type will have a different representation. Conversion to class-wide and back will be proper conversion, not a view conversion. Then for this case, the class is not Root_Integer'Class, but Printable'Class. Yes, Integer should be a member of. > Most likely, one would have to add a level of indirection into most > objects. That sort of distributed overhead is typically frowned on in Ada. No overhead in any existing code. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de