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 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 03:34:19 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!news-out.tin.it!news-in.tin.it!news.finmeccanica.it!not-for-mail From: "Davide" Newsgroups: comp.lang.ada Subject: Re: data types & efficiency Date: Mon, 8 Mar 2004 11:53:45 +0100 Organization: Finmeccanica Message-ID: References: <5ohg40ls073v1b5d8idail4t365f57l8os@jellix.jlfencey.com> NNTP-Posting-Host: 192.168.54.114 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xref: archiver1.google.com comp.lang.ada:6136 Date: 2004-03-08T11:53:45+01:00 List-Id: Vinzent 'Gadget' Hoefler wrote: >Hmm, strange requirements. Sounds a little bit like someone just wants >stdint.h> in Ada. ;) Okay, I thanks all the newsgroup in a previous post (including also you, of course) before receiving this post. And I found this post very interesting. Yes, for what concerns C heritage, this depends on me, I'm a "C++"er and Ada typing philosophy is ...ehm..just a little bit different... >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. > >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). Thanks a lot for this contribution. My experiment was misleading. >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. :) Now I'm curious. I hope some language lawyers will answer. >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. I must apologize. Your reasoning is perfect. I misunderstood the requirements. As you said, forcing the representation makes sense only if the interested type has to map some data on some external hardware. For the other types the only right thing to do is to let the compiler be free to optimize. Indeed my requirements meant to say that, in general, I shall not use predefined LONG_INTEGER, SHORT_INTEGER,... types but I shall specify the range explicitely. The range, not the size. This is to avoid different *ranges* associated to the same predefined type for different compilers. This is my new understanding of requirements, that were not written so clear...unfortunately :(( Anyway from this discussion I learned a lot of things, and I thank you. Davide