From: Ludovic Brenta on
"Jeffrey R. Carter" <ggsub(a)pragmada.x10hosting.com> writes:

> On Apr 19, 9:24 am, Ludovic Brenta <ludo...(a)ludovic-brenta.org> wrote:
>>
>> If you want to avoid the 16## part, you can easily convert the
>> stream_elements to a string representation yourself like so:
>>
>> function To_Hex (E : in Ada.Streams.Stream_Element) return String is
>
> This seems unnecessarily complex to me. Using the standard library to
> put an element to a String in base 16, then stripping the "16#" from
> the front and '#' from the end seems simpler, clearer, and less error
> prone.

I find it funny you should say that because I thought exactly the
opposite: letting Ada.Text_IO (which is notoriously slow) do the
conversion to string and then doing string manipulation is less clear
and more error-prone, IMHO (a proper implementation would use a simple,
but full-fledged, finite state machine). But your approach is certainly
valid and correct nevertheless.

--
Ludovic Brenta.
From: John B. Matthews on
In article <Xns9D5F9D5EB3703WarrensBlatherings(a)81.169.183.62>,
Warren <ve3wwg(a)gmail.com> wrote:

> I hate these dos names that gnat uses for the spec file names.

Same here. Using GNAT, `gnatkr` can be used to find a file from a name
in the API. Say you are reading "A.10.1 The Package Text_IO", you can
pull up the specification with a command such as this:

$ more $ADA_INC/$(gnatkr Ada.Text_IO.ads)

where $ADA_INC point to the run-time library include files.

<http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gnat_ugn_unw/File-Name-Krunching-Using-gnatkr.html>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
From: Adam Beneschan on
On Apr 19, 12:28 pm, Warren <ve3...(a)gmail.com> wrote:
> Jeffrey R. Carter expounded in news:e5748cb1-0e95-49ff-8616-
> 6709c6dd7...(a)q15g2000yqj.googlegroups.com:
>
>
>
>
>
>
>
> > On Apr 19, 11:05 am, Warren <ve3...(a)gmail.com> wrote:
>
> >> I've been interested in finding these ways to "Put" (Hex) to
> >> a string, instead of a File_Type.
>
> >> But what I've seen is that "Put" always involves a
> >> File_Type (or implies one).
>
> >> So what have I missed?
>
> > From A.10.8 (Input-Output for Integer Types):
> ...
> > procedure Put(To   : out String;
> >               Item : in Num;
> >               Base : in Number_Base := Default_Base);
> > 19
> > Outputs the value of the parameter Item to the given string, following
> > the same rule as for output to a file, using the length of the given
> > string as the value for Width.
>
> My apologies-- I see it now. I hate these dos names
> that gnat uses for the spec file names. I see the
> api now.
>
> Now if only I could find where the mayonnaise in the
> fridge is..

It got shoved in the back, behind that leftover chicken casserole
that's been there way too long and needs to be thrown out.

Hope this helps,

-- Adam
From: Jeffrey R. Carter on
On Apr 19, 1:52 pm, Ludovic Brenta <ludo...(a)ludovic-brenta.org> wrote:
>
> I find it funny you should say that because I thought exactly the
> opposite: letting Ada.Text_IO (which is notoriously slow) do the
> conversion to string and then doing string manipulation is less clear
> and more error-prone, IMHO (a proper implementation would use a simple,
> but full-fledged, finite state machine).  But your approach is certainly
> valid and correct nevertheless.

Funny you should say that ...

Considering that I can write

function Hex_Image (Number : Ada.Streams.Stream_Element) return String
is
Result : String (1 .. 10);
Start : Natural;

package Stream_Element_IO is new Ada.Text_IO.Modular_IO (Num =>
Ada.Streams.Stream_Element);
begin -- Hex_Image
Stream_Element_IO.Put (To => Result, Item => Number, Base => 16);
Start := Ada.Strings.Fixed.Index (Result, "#") + 1;

return Result (Start .. Result'Last - 1);
end Hex_Image;

and get it right 1st time, compared to the issues you encountered
duplicating (some of) the functionality of Put, seems to me evidence
that this approach is less error prone. I certainly find it simpler
and clearer, too.

Getting this to return a zero-filled String of the correct number of
digits is slightly more complex:

Num_Chars : constant := Ada.Streams.Stream_Element'Size / 4;

Result : String (1 .. Num_Chars + 10);

....

return String'(1 .. Num_Chars - (Result'Last - Start) => '0') & Result
(Start .. Result'Last - 1);
From: Jeffrey R. Carter on
On Apr 20, 12:25 am, Stephen Leake <stephen_le...(a)stephe-leake.org>
wrote:
>
> generic
>    Width : Natural;
>    type Number_Type is mod <>;
> function SAL.Generic_Hex_Image (Item : in Number_Type) return String;
> --  Return a hexadecimal image of Item, padded with leading zeros to
> --  Width. If Width is too small for Item, leading digits are silently
> --  truncated.

So if I sometimes want different widths for the same type, I have to
have multiple instantiations? That doesn't seem very friendly to me. I
don't see why Width couldn't be a parameter of the function, probably
defaulted to Number_Type'Width.

What do I do for signed integer images, for bases other than 16, and
for signed integer images for bases other than 16? Do I have to roll
my own for these cases?

In Ada.Text_IO, a Width of zero implies the minimum width needed to
represent the value; here it's an expensive way to get a null String.
I'd prefer consistency with the standard.

I haven't used SAL, but these are the kind of comments you'd probably
get from me if I did use this function. HTH.