for S'Image use Func??
in [ADA]
|
Prev: Question about default discriminants and mutable objects.
Next: Why is not Stream_Access defined Ada.Streams ?
From: Ludovic Brenta on 10 May 2010 17:30 Maciej Sobczak <see.my.homepage(a)gmail.com> writes: > Coming back to I/O - what I miss in Ada is the equivalent of fread in > C - that is, an operation that reads *up to* the given number of > bytes. Or maybe there is something that I didn't notice? Such an > operation is an important basis for custom buffered input. Without it > the only way to reinvent a proper I/O is via direct bindings to > system- level API. Ada.Streams.Read (ARM 13.13.1(5)) does just that. So does Ada.Text_IO.Get_Line (ARM A.10.1(49)). -- Ludovic Brenta.
From: Yannick Duchêne (Hibou57) on 10 May 2010 18:24 Le Mon, 10 May 2010 22:56:11 +0200, Maciej Sobczak <see.my.homepage(a)gmail.com> a écrit: > In C files are designated by pointers *always*, not sometimes. Only as long as you only rely on fopen ; there is also an "int open(char * filename, int flags)" which is widely used. Weither or not this "int" actually stands for a pointer is another story (as in C one will always be able to cast from int to void*, this may be true indeed). -- No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just not lucky
From: Niklas Holsti on 11 May 2010 03:34 Warren wrote: > Niklas Holsti expounded in news:84r4k5Ftk8U1(a)mid.individual.net: >> ... if you read character by character, use the function >> Text_IO.End_Of_Line to detect the end of an input line. This works >> the same way in all systems, whatever line termination character >> (sequence), if any, is used. Follow with Skip_Line to go to the start >> of the next line. > > I assume that is true before you read the next "char". If I > then Skip_Line as you say, will I also get End_Of_Line true > if the next line is empty (null)? Yes, with one problem, which is that it is hard (that is, I don't know how) to detect when the very last line in the input file is null. This is because End_Of_Line returns true also at end of file, and End_Of_File returns true also when the data remaining in the file is an end-of-line (and end-of-page) before the true end of file. One consequence is that a truly empty file (like /dev/null) looks the same as a file with one null line (like echo ""). Try this program on a file with some empty lines: with Ada.Text_IO; use Ada.Text_IO; procedure Linelen is K : Character; Len : Natural; begin while not End_Of_File loop Len := 0; while not End_Of_Line loop Get (K); Len := Len + 1; end loop; Put_Line ( "Line" & Count'Image (Line) & " has" & Natural'Image (Len) & " characters."); Skip_Line; end loop; end Linelen; -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .
From: Maciej Sobczak on 11 May 2010 03:42 On 10 Maj, 22:24, Georg Bauhaus <see.reply...(a)maps.futureapps.de> wrote: > > Coming back to I/O - what I miss in Ada is the equivalent of fread in > > C - that is, an operation that reads *up to* the given number of > > bytes. Or maybe there is something that I didn't notice? > Streams.Read and overridings should achieve this? That's right. Thank you (and others) for reminding me of this. Of course the overridings are the most crucial here and Streams.Stream_IO should do the job. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Yannick Duchêne (Hibou57) on 11 May 2010 03:56
Le Tue, 11 May 2010 09:34:42 +0200, Niklas Holsti <niklas.holsti(a)tidorum.invalid> a écrit: > Yes, with one problem, which is that it is hard (that is, I don't know > how) to detect when the very last line in the input file is null. This > is because End_Of_Line returns true also at end of file, and End_Of_File > returns true also when the data remaining in the file is an end-of-line > (and end-of-page) before the true end of file. One consequence is that a > truly empty file (like /dev/null) looks the same as a file with one null > line (like echo ""). This may be "hard" only with the Standard_Input file, which is a Text_IO.File_Type, and Text_IO, as previously said, is a file of lines. A file of line, as you shown you know, is a file where each is line strictly delimited in platform dependent manner (with LF on UNIX, CR+LF on Windows and CR on Mac, or with specific chunks or records on some other systems).. So obviously, each line is expected to have an end, just like each file have an end, and the end of the last line is also the end of a file, if the file is a file of line. Just like a file of some kind of records ends with the end of the last record. I was to say this is a matter only with Standard_Input, and in the context of "/dev/null" which you gave, you have no need to open "/dev/null" as a file of lines if have no reason to think "/dev/null" is indeed a file of lines. To talk about text files now : let say most of them are just inconsistently formated, as many text files as produced by text editors, are not formated in the constant way : the last line oftenly lacks a delimiter for the last line. This files are either invalid files of lines or else are not files of lines, depending on your requirement. If your requirements states that a line is a sequence of character terminated by a CR+LF or an LF or a CR, then, the file you need is a file of characters, so don't open these files as file of lines, better as file of characters instead. The only remaining case is the one of the standard input. -- No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just not lucky |