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: J-P. Rosen on 12 May 2010 01:00 Warren a �crit : > J-P. Rosen expounded in news:hsb97m$tnd$1(a)news.eternal-september.org: > >> Dmitry A. Kazakov a �crit : >>> On Mon, 10 May 2010 18:50:02 +0000 (UTC), Warren wrote: >>> >>>> But you have no way to know when you've read >>>> a empty line in a lexer routine that is reading >>>> character by character. >> Come on, here is the magic function: >> >> function Empty_Line return Boolean is >> begin >> return Col=1 and End_Of_Line; >> end Empty_Line; > > There's a wart-- see earlier posts about "end file". > Of course, this assumes an well-formed Ada file. FYI, there /is/ a scanner in AdaControl, and I never had a problem. The trick is to check End_Of_Line when needed, and never check End_Of_File, but handle End_Error instead. This works even for ill-formed files. And of course, you are welcome to have a look at my scanner in AdaControl ;-) -- --------------------------------------------------------- J-P. Rosen (rosen(a)adalog.fr) Visit Adalog's web site at http://www.adalog.fr
From: Maciej Sobczak on 12 May 2010 09:16 On 11 Maj, 23:46, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > > OK, next step: what's exactly being inefficient in buffering in > > buffered input? > > Machine instructions to execute. Yes - by proper use of buffering I can *reduce* the number of machine instructions to execute and therefore make the program run faster. Note also that the number of machine instructions is only a partial problem - another is delays introduced by some of them. Sometimes it is better to execute more instructions that keep the pipeline full than to execute less of them, but with delays or blocks. > Why an Ada program handling texts need to be aware of your system? Because it is running on my system. It's a pretty good idea to have some local awareness. > Ada.Text_IO provides an OS-independent abstraction of a text. The above is not even wrong. Ada.Text_IO cannot even *name* all the files that I have on my hard drive. Even assuming that I can open some file, the whole "abstraction of a text" is severely limited. I cannot, for example, read the second paragraph of the third chapter of the book that is in the file. This "abstraction" is really a stream on steroids, nothing fancy. > > Unfortunately, in Ada the formatting and I/O are entangled in Text_IO. > > No. See A.10.8(18) and F.3.3. Wrong. They do not relate to Text_IO. Even assuming wider context, formatting without I/O is trivial, but I cannot have I/O without formatting. Text_IO gives me both. But on the other hand, I'm not sure how I/O without formatting would look like - that would have to be a plain stream. Which means that your "abstraction of a text" is little more than a bit of formatting glued on top of a stream. > The problem of Text_IO is columns. Not only. It cannot detect the end of stream without blocking, for example. > 2. Stream I/O is unsuitable for a custom Text_IO. It simply won't work in a > system deploying native record-oriented files. I'm OK with that. The whole thing is so unportable already that limiting it further to only those systems that I will ever want to use is not a problem for me. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Warren on 12 May 2010 09:27 Dmitry A. Kazakov expounded in news:1x8q3p2gvm9fh.aru6nueicagd$.dlg(a)40tude.net: > On Tue, 11 May 2010 20:56:11 +0000 (UTC), Warren wrote: > >> Dmitry A. Kazakov expounded in news:1qfu2ba65pd63$.asc7m201hi6u$.dlg@ >> 40tude.net: >> >>> On Tue, 11 May 2010 17:17:38 +0000 (UTC), Warren wrote: >>> >>>> =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= >>>> expounded >> in >>>> news:op.vcig7go1ule2fv(a)garhos: >>>> >>>>> Le Mon, 10 May 2010 22:56:11 +0200, Maciej Sobczak >>>>> <see.my.homepage(a)gmail.com> a écrit: >>>>>> 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? >>>> >>>>> It's there : look at [ARM 2005 13.13.1] which defines the package >>>>> Ada.Streams, which in turn contains the following : >>>>> >>>>> type Root_Stream_Type is abstract tagged limited private; >>>>> ... >>>>> type Stream_Element is mod implementation-defined; >>>>> ... >>>> ... >>>>> Well, to be honest, this is not exactly the same as with C, as >>>>> Ada.Streams.Stream_Element is implementation defined (which is >>>>> good, because this is indeed platform dependent), so you will >>>>> need .. >>>> >>>> All this is well and good for applications that can work in >>>> "implementation defined" units of type Stream_Element. A pragma >>>> won't fix the problem should it be different than a byte. Granted, >>>> it will never likely come up on the platforms I have in mind. >>> >>> If you to read a character stream, just do so: >>> >>> Item := Character'Read (S); >>> Character'Write (S, Item); >>> >>> For octet streams use Unsigned_8. >> >> But this has to include seeking in the stream as well. > > Repeat reading n times. > >> Can you guarantee seeking to an arbitrary "byte boundary"? > > On a machine with 13 bis per character? Can you define "byte > boundary"? The point is that if Stream_Element is not 8 bits, and the > environment supports streams of octets, then I see no reason why Ada > vendor would implement Unsigned_8r'Read incompatible with that. On those machines, you're not going to have standard C I/O either. That's an purely academic case. But the issue I am taking, are machines that define multiples of a byte. Warren
From: Warren on 12 May 2010 09:33 Gautier write-only expounded in news:58bc837c-16b5-4a9d-af74-40417ad538c5(a)k29g2000yqh.googlegroups.com: > On May 11, 12:39�am, Yannick Duch�ne (Hibou57) > <yannick_duch...(a)yahoo.fr> wrote: > > [...] >> Well, to be honest, this is not exactly the same as with C, as � >> Ada.Streams.Stream_Element is implementation defined (which is good, >> � because this is indeed platform dependent), so you will need an >> Assert > � >> pragma somewhere is your application, which ensures � >> Ada.Streams.Stream_Element is 8 bits or at least 8 bits (this is, in >> most > � >> of case), and then convert from Ada.Streams.Stream_Element to your � >> Byte_Type or anything your application defined as such. ... > You can make a size check (even a compile-time one!). Here, for > arrays: > subtype Size_test_a is Byte_Array(1..19); > subtype Size_test_b is Ada.Streams.Stream_Element_Array(1..19); > -- > is_mapping_possible: constant Boolean: Size_test_a'Size = > Size_test_b'Size and then > Size_test_a'Alignment = Size_test_b'Alignment; I suspect that Ada.Streams.Stream_Element being > 1 byte, is probably academic for my purposes. However, if a posix platform made a stream element 2 or 4 bytes, then the "whole gig is off". Which is what my OP was about. Should that happen, I'd be forced to look at bindings to something else. But this is probably academic. Warren
From: Yannick Duchêne (Hibou57) on 12 May 2010 10:33
Le Wed, 12 May 2010 15:16:05 +0200, Maciej Sobczak <see.my.homepage(a)gmail.com> a écrit: > The above is not even wrong. Ada.Text_IO cannot even *name* all the > files that I have on my hard drive. > > Even assuming that I can open some file, the whole "abstraction of a > text" is severely limited. I cannot, for example, read the second > paragraph of the third chapter of the book that is in the file. > This "abstraction" is really a stream on steroids, nothing fancy. Talking about names, it happens I myself had troubles on Windows XP with some file names too (exceptions on directory iteration, raised when the file name contains some characters). If that can make you happy, some real life projects too, requires no dependency at all on Ada.Text_IO and and other File_Type related things coming from standard packages. It is even part of some really used control file examples which comes with AdaControl ( http://www.adalog.fr/adacontrol1.htm ) If something is not suitable to you, nothing in the standard requires you to use it ;) It is really common to use Ada with restrictions to enforce some requirements. That does not mean these libraries are not good, just that they may not meet some expectations. Ada's standard library set is rather tiny (that's what is good) compared to others, so it cannot meet every ones expectations. There is more benefit in being able to create the package you need and which is not provided by the standard, and be able to do it well and cleanly, than to have standard package to âmeetâ all requirements (not possible). Perhaps Ada is more âready to createâ than âready to cosumeâ That was my two cents of the day, sorry if that was not so much worthy -- pragma Asset ? Is that true ? Waaww... great |