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=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.68.206.102 with SMTP id ln6mr7044414pbc.13.1438517722571; Sun, 02 Aug 2015 05:15:22 -0700 (PDT) X-Received: by 10.140.92.81 with SMTP id a75mr98803qge.14.1438517722525; Sun, 02 Aug 2015 05:15:22 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!f3no6331641igg.0!news-out.google.com!78ni3197qge.1!nntp.google.com!69no3411971qgl.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 2 Aug 2015 05:15:22 -0700 (PDT) In-Reply-To: <38dbb43b-4d60-4d3c-8da5-7fba799309f6@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=81.203.145.32; posting-account=AFCLjAoAAABJAOf_HjgEEEi3ty-lG5m2 NNTP-Posting-Host: 81.203.145.32 References: <2df4698f-4c8e-457c-822d-209cb2f8ab5e@googlegroups.com> <014427b1-ff7a-4a69-82e6-0330af77ed96@googlegroups.com> <38dbb43b-4d60-4d3c-8da5-7fba799309f6@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Running a preprocessor from GPS? From: EGarrulo Injection-Date: Sun, 02 Aug 2015 12:15:22 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: news.eternal-september.org comp.lang.ada:27325 Date: 2015-08-02T05:15:22-07:00 List-Id: On Sunday, August 2, 2015 at 12:08:52 PM UTC+2, EGarrulo wrote: > On Friday, July 31, 2015 at 2:23:20 AM UTC+2, Randy Brukardt wrote: > > "EGarrulo" wrote in message > > > 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). > > > > 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). Additionally, elementary types > > are by-copy; that would prevent the techniques used for tagged types from > > working. 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. > > > > Indeed, if the second case was allowed in Ada, it definitely would NOT > > represent different types. The check would be some sort of constraint check > > (similar to the tag check of tagged types). "Any" would represent any type, > > and thus would never fail type matching. > > Right. A proper type-safe and efficient solution would require the use of > generics but, right now, C++ is the only language whose generics are complete > enough to implement such a solution. In Ada, we are stuck with performing the > job of Printf by hand, or sacrifice performance. If I recall correctly, Ada was the first standardized language that introduced generics. Then other languages caught up and nowadays they lead the way. Yet, I am sure that Ada will catch up in the future.