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,8b5b40006550b942 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-03-08 07:27:38 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!chcgil2-snh1.gtei.net!news.bbnplanet.com!nycmny1-snf1.gtei.net!news.gtei.net!colt.net!pop-news-1.colt-telecom.nl!newsfeed.wirehub.nl!newsfeed.multikabel.nl!213.51.129.3.MISMATCH!newshub1.home.nl!home.nl!news.cambrium.nl!news.cambrium.nl!ecngs!feeder.ecngs.de!38.119.100.83.MISMATCH!news-out1.nntp.be!propagator2-sterling!news-in-sterling.newsfeeds.com!border2.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Mon, 08 Mar 2004 09:27:31 -0600 Date: Mon, 08 Mar 2004 10:27:30 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: data types & efficiency References: <5ohg40ls073v1b5d8idail4t365f57l8os@jellix.jlfencey.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.77.160 X-Trace: sv3-ISunvT188BNcXw1n3pQIKP7yHrxy18v+cUILaBUnIUin1QFHWLStdpSTewGUjxT8+LJFeRFPpRX58LA!eHInHhbewwM+1vMMUpH0MOp3GPv7ktOwW++sghcBy8XNfz97ULkJqoLhCy4z+g== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:6147 Date: 2004-03-08T10:27:30-05:00 List-Id: Vinzent 'Gadget' Hoefler wrote: > No, it can't (at least I think so). It can do this if you derive a > "new" type from it, but not for a subtype. A subtype always has the > same representation as its base type. > > Hmm, at least that's *my* interpretation of the RM, so it can be > totally wrong. :) Correct, your interpretation is totally wrong. ;-) You can specify different sizes for both objects RM 13.3(39..43) and subtypes RM 13.3(44..56). But notice the note at RM 13.3(58): "A component_clause or Component_Size clause can override a specified Size. A pragma Pack cannot." In other words, a 'Size clause for a subtype can be overridden. > So, yes, for the subtype it "optimizes" the size (it simply spits out > the minimum size needed to represent the specified range) -> > Smaller_Int'Size gives 6 here. Correct, RM 13.3(55) recommends that if the size of the subtype is NOT specified, S'Size should return the minimum size required for an unbiased representation. Note that an implementation will often use a larger size for objects of the subtype whose size is unspecified, and may allow a smaller size to be used in records (fierce packing). I think GNAT has another attribute that returns the size that will be used for standalone object of the type. > But for an actual object of that subtype it uses that of the base > type, of course (y'Size gives 32, too) - unless you specify a > different size for the object itself (z'Size gives 8). > > To be honest, my understanding of RM 13.3(39-57) is not very good. So > it is perhaps better to delegate this question to the real language > lawyers here in c.l.a. :) This is/was not a good time for that, there was an ARG meeting this weekend. > Well, it seems you can't define a representation for a subtype, only > for an object of that subtype. No, see above. > Given that, your "requirements" don't make much sense too me, because > even if you define a representation for each of the "redefined" types, > you still can change for each object declared, if you need to do so. > > And BTW, "independence from the compiler in terms of internal > representation" really sounds quite unportable to me. For instance, if > you try to do that on a 24-bit DSP, there is no 32-bit representation > available at all, simply because the target-architecture can't do that > (it must be either 24 or 48 bits). But the possibility of defining an > Integer that can represent 2**32 different values is still there. > > So IMO doing such things would break more that it could possibly fix. If what you want is for the compiler to reject programs when it can't implement the required sizes, well that is what you asked for. If you want to force overflow when an intermediate value is out of bounds, this doesn't work. What you need to do in that case is either specific assignments, or better, subtype conversions where you want to be sure that an intermediate is a value of the subtype. Converting to a subtype does a range check, RM 4.6(51), that cannot be optimized away by RM 11.6(5). (Explicit conversions are not operations...) However, note that no check is performed for a subtype conversion of an out parameter RM 4.6(62). This is to prevent the passing of an uninitiallized value as an out parameter from raising Constraint_Error. (When you think about it, this should be a non-issue, the check is only omitted for values that can't be used anyway. However, there are some cases in generics where the effect can be surprising.) In practice what most people who are trying to write portable software do is to carefully specify (sub)types that are used for input or output, and let the compiler use the most efficient types internally. And yes, this sometimes means that the (sub)types used for I/O are different from those used internally. This way, if there is a difficult or expensive conversion, it only occurs as part of the I/O. -- Robert I. Eachus "The only thing necessary for the triumph of evil is for good men to do nothing." --Edmund Burke