From: Ludovic Brenta on 19 Apr 2010 16:52 "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 19 Apr 2010 19:21 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 19 Apr 2010 19:22 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 19 Apr 2010 19:34 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 20 Apr 2010 18:21 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.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Hexadecimal and stream element arrays Next: Help - removal from asiswg-members.html |