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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,2e6723b897ab47fb X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Received: by 10.216.235.32 with SMTP id t32mr671394weq.7.1344847804784; Mon, 13 Aug 2012 01:50:04 -0700 (PDT) Path: n2ni106810644win.0!nntp.google.com!feed-C.news.volia.net!volia.net!news2.volia.net!feed-A.news.volia.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!xlned.com!feeder5.xlned.com!feed.xsnews.nl!border-2.ams.xsnews.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!80.86.168.138.MISMATCH!news-feed.eu.lambdanet.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada.Locales pseudo-string types Date: Wed, 08 Aug 2012 11:17:46 +0300 Organization: Tidorum Ltd Message-ID: References: <78707b6e-88a3-453a-a37c-840f7a62e703@googlegroups.com> <7303f906-0f6a-4d97-ae15-36b4056ede6c@googlegroups.com> <257b4f44-b6c6-4c79-8c6e-dec947a3ce25@googlegroups.com> Mime-Version: 1.0 X-Trace: individual.net HRmAuLfw3UP6trKmayxs+wTFeAHo8sCyVmGjrwB8U7Fyvb7lrby3oIj8Qj8zN5Qiwe Cancel-Lock: sha1:YisJOKdP+aCP6l84bndo+ENmffQ= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: 2012-08-08T11:17:46+03:00 List-Id: On 12-08-08 10:32 , J-P. Rosen wrote: > Le 08/08/2012 09:04, Niklas Holsti a �crit : >> The rule does seem surprisingly rigid, for a value conversion. (The >> Annotated RM does not explain or motivate it.) For a value conversion, >> the default could be to convert element by element, and the compiler >> could then optimize this conversion based on what it can deduce >> statically about the matching of the source and target subtypes. > One of the founding principles of Ada was "no hidden inefficiencies" > (whether this has been achieved is another story). Since an array can > have many elements, this could be quite costly. This is understood. Whether this inefficiency is "hidden" is debatable, of course. > And of course, it would force pass-by-copy I don't think so. If the source and target element subtypes statically match, or match well enough that no element conversions are necessary (as in the original Ada.Locales example), the compiled code could be the same as compilers use now. In other cases, the compiler could create a temporary array to hold the result of the conversion, and pass this array by reference. I admit that this could lead to cases where a small change in the types makes the compiler switch from the fast, no-copy, pass-by-reference code to the slower element-by-element copying code, which could cause a surprising drop in performance. Users might want compilers to warn them about such cases. >> In the example, the compiler should be able to deduce that >> element-by-element conversion is unnecessary since the source element >> subtype is a subrange of the target element subtype. > But if the conversion is used for an in-out parameter, it implies the > opposite conversion - where nothing can be deduced. > > And you don't want a special rule that works only for in parameters, "In" parameters already have special rules, since conversions for "in" parameters are considered value conversions rather than view conversions. > and only with compilers that pass arrays by copy, would you? So the movation for the present static-match rule is that it makes it simple for compilers always to pass arrays by reference, even when the array is the result of a type conversion. (I suppose it is a quibble to point out that a compiler is nevertheless not forced to pass by reference.) But the rule is still stronger than necessary. For value conversions, including "in" parameters, the exact match could be replaced by a static check that the constraints on the source elements are the same as or stronger than those on the target elements. This would allow Ada.Text_IO.Put (String (Some_Country_Code)). For "out" parameters, there could be a static check that the constraints on the actual (source) array elements are the same as or weaker than those on the formal (target) array elements. For "in out" parameters, the present static-match rule would be kept, as the logical conjunction of the "in" and "out" rules. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .