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 11 May 2010 16:53 =?iso-8859-15?Q?Yannick_Duch=EAne_=28Hibou57=29?= expounded in news:op.vcj1wgldxmjfy8(a)garhos: > Le Tue, 11 May 2010 19:05:07 +0200, Warren <ve3wwg(a)gmail.com> a �crit: >> As I pointed out earlier, those *printf() arguments are >> checked, so it is not strictly untyped. You can lie to >> it of course.. > Isn't it checked at the compiler option ? > > Does ANSI or ISO C really requires this ? > > If so, how is it formalized ? It may only be GNU's compiler that checks this. You may also need compiler options to trigger it (I almost always turn all but the most troublesome checks as routine practice). The Sun compiler might but I've never checked it. Warren
From: Warren on 11 May 2010 16:56 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. Can you guarantee seeking to an arbitrary "byte boundary"? I'm asking because I'm too lazy right now to look it up. But IIRC, the best you can do is the Ada.Streams.Stream_Element. Warren
From: Warren on 11 May 2010 17:08 =?utf-8?Q?Yannick_Duch=C3=AAne_=28Hibou57?= =?utf-8?Q?=29?= expounded in news:op.vcj1lsgkule2fv(a)garhos: >> A pragma >> won't fix the problem > No language will fix the problem if you need a 8 bits file storage > element on a platform which uses something else. > >> should it be different than a byte. Granted, >> it will never likely come up on the platforms I have in mind. > So, what' wrong ? Why is this so difficult to understand? POSIX systems do this all the time with the standard I/O irregardless of what the machines "storage element" unit is. What I'm suggesting is needed is a layer (pkg) that makes it appear to the application that you can seek to byte boundaries, get and write bunches of bytes, at arbitrary byte lengths without a single care of whether the host machine supports 32, 64, or even 36 bit words (I onced did C on a Honeywell L66, with 9-bit bytes, 18-bit half words and 36-bit words). Yet the C I/O package gave me the POSIX friendly FILE api to work with. So I don't buy the "it can't be done" thinking. Move away from Ada streams for a moment and think about what "could be done". All it requires is probably a thin layer on top of Ada streams, except where they two are one ;-) The they can appear as two, but have a common implementation. > Ada will simply not be able to be POSIX friendly on platforms which > are not POSIX. Have you tried cygwin and gnat? They work rather well in its simulated POSIX environment. It breaks down in a few "peculiar" places granted, but overall it's great on the company laptop, when the corporation sez "u must have windoze". Warren
From: Dmitry A. Kazakov on 11 May 2010 17:46 On Tue, 11 May 2010 13:18:39 -0700 (PDT), Maciej Sobczak wrote: > On 11 Maj, 16:24, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > >>> OK, really - what's exactly being inefficient in buffered input? >> >> You said it, it is buffering. > > OK, next step: what's exactly being inefficient in buffering in > buffered input? Machine instructions to execute. >>> What I want is a stream interface to the blobs that my filesystem is >>> storing for me, so that I can build higher-level constructs on top of >>> it. >> >> But if my file system already has get-line-as-an-array-of-code-points. Why >> should I go deeply down to the representation layer, to a stream of octets? > > Then you shouldn't. The point is that *my* filesystem does not have it > (it supports only blobs), so I have a valid use-case for stream of > octets. Why an Ada program handling texts need to be aware of your system? Ada.Text_IO provides an OS-independent abstraction of a text. It is a poor abstraction of a stream, it is even a poorer abstraction of space travel. So what? >>>> The bottom line is, Ada does it right (tm). >> >>> If it did it right (tm), I would not have to reinvent >>> My_Better.Text_IO. >> >> You should not. The question was about formatting, I/O is OK. > > Unfortunately, in Ada the formatting and I/O are entangled in Text_IO. No. See A.10.8(18) and F.3.3. The problem of Text_IO is columns. It was an important feature back in late 70's, but it is totally useless today. > They are "separate" in stream I/O (there is no formatting at all > there) and this is what makes stream I/O a valid basis for a custom > solution, like My_Better.Text_IO. That's exactly my point. I am not sure what do you mean here. 1. Formatting is unrelated to either line-oriented (in earlier times one called it record-oriented) or character-stream oriented I/O. 2. Stream I/O is unsuitable for a custom Text_IO. It simply won't work in a system deploying native record-oriented files. And it would be just silly to emulate a stream on top of records, encode it (to escape delimiters) and then decode back to implement Get_Line! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 11 May 2010 18:06
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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |