comp.lang.ada
 help / color / mirror / Atom feed
From: "Davide" <ppp@ppp.it>
Subject: Re: data types & efficiency
Date: Mon, 8 Mar 2004 11:53:45 +0100
Date: 2004-03-08T11:53:45+01:00	[thread overview]
Message-ID: <c2hjbo$qm$1@e3k.asi.ansaldo.it> (raw)
In-Reply-To: bddo40190ttpdpdl5tibj6b09itpk3ad01@jellix.jlfencey.com


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







  reply	other threads:[~2004-03-08 10:53 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-05  8:02 data types & efficiency Davide
2004-03-05  9:23 ` Vinzent 'Gadget' Hoefler
2004-03-05  9:57   ` Davide
2004-03-05 12:00     ` Vinzent 'Gadget' Hoefler
2004-03-05 15:54       ` Davide
2004-03-05 20:53         ` tmoran
2004-03-08  9:28           ` Davide
2004-03-08  8:58         ` Vinzent 'Gadget' Hoefler
2004-03-08 10:53           ` Davide [this message]
2004-03-08 15:27           ` Robert I. Eachus
2004-03-05 10:22 ` Jean-Pierre Rosen
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox