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: Warren on 10 May 2010 16:16 Niklas Holsti expounded in news:84r4k5Ftk8U1(a)mid.individual.net: > Warren wrote: >> Dmitry A. Kazakov expounded in >> news:1qcb6z4i20dyb.1dz2hd4c0vx69.dlg(a)40tude.net: >> >>> On Mon, 10 May 2010 16:52:18 +0000 (UTC), Warren wrote: >>>> But if I recall correctly, I also cannot get an >>>> empty string as input. An empty string is still >>>> valid input. >>> Hmm, try this: >> >> Ok, good- that at least works. >> >> But you have no way to know when you've read >> a empty line in a lexer routine that is reading >> character by character. > > Yes you do... > >> What you end up having to do is to >> test for line number changes instead-- yuk. > > ... 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)? If true, then it may be time for me to reconsider how my current lexer works. > To return to the subject: I too often use 'Image for normal output, > not just for debugging. And I find the extra blank annoying. But it is > a very small annoyance, considering what else life offers :-) I just now use: function Trim(S : String) return String is begin for X in S'Range loop if S(X) /= ' ' then return S(X..S'Last); end if; end loop; return ""; end; to trim off leading the blanks. This could be simpler, if you only use it for S'Image. ;-) Thanks for the tip, Warren
From: Simon Wright on 10 May 2010 16:38 Warren <ve3wwg(a)gmail.com> writes: > function Trim(S : String) return String is > begin > for X in S'Range loop > if S(X) /= ' ' then > return S(X..S'Last); > end if; > end loop; > return ""; > end; I've used a renaming of Ada.Strings.Fixed.Trim with Side defaulted to Ada.Strings.Both.
From: Warren on 10 May 2010 16:52 Simon Wright expounded in news:m2bpcnjxuw.fsf(a)pushface.org: > Warren <ve3wwg(a)gmail.com> writes: > >> function Trim(S : String) return String is >> begin >> for X in S'Range loop >> if S(X) /= ' ' then >> return S(X..S'Last); >> end if; >> end loop; >> return ""; >> end; > > I've used a renaming of Ada.Strings.Fixed.Trim with Side defaulted to > Ada.Strings.Both. Hi Simon: I was aware of that, and not really sure if I saved anything (I didn't check) by doing it myself. But I knew I didn't care about the right trim etc. I wouldn't be surprised if something buried in the libraries uses it anyway, so perhaps I should use it also. Warren
From: Maciej Sobczak on 10 May 2010 16:56 On 10 Maj, 19:55, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > >> C's I/O is a disaster, > > > You have only listed an opinion when you don't > > list specifics. > > Did you used it? Character input returns integer, Interestingly, same as in Java. I believe that they should have done it with a separate flag instead of inflating the state space by using bigger type. > file is a number, The C programming language does not define files as numbers. > sometimes a pointer, In C files are designated by pointers *always*, not sometimes. > do you use fseek or lseek? Again confusion - lseek is not part of C. > Is errno thread safe in > UNIX? (What does C say about threads?) C says nothing about threads. But that's OK, because you do not ask about C in isolation, but about its interaction with Unix. That is, the thread-safety of errno in Unix is defined by appropriate Unix standards: http://www.unix.org/whitepapers/reentrant.html (see "Redefinition of errno") > We constantly > fight with catching: > > printf ("%s", X); > > X is an object of the type having implicit conversion to const * for output > purpose. Then wait until your programmers start learning C++ and begin to delete such objects... :-) 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. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Georg Bauhaus on 10 May 2010 16:24
Maciej Sobczak 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? 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. Streams.Read and overridings should achieve this? Read fills an array of a given size with up to at most the array's length stream_elements. |