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: Maciej Sobczak on 11 May 2010 03:58 On 11 Maj, 00:24, Yannick Duchêne (Hibou57) <yannick_duch...(a)yahoo.fr> wrote: > Only as long as you only rely on fopen ; This function is defined in the C standard. > there is also an "int open(char * > filename, int flags)" which is widely used. This one is not defined in the C standard and as such is not part of the C language. > 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 this is not true either - assuming that you mean the "open" function defined in the POSIX standard, the return value is the lowest *numbered* unused file descriptor. This is aligned with the semantics of other functions like select. Another reason for why this cannot be a pointer is that NULL is defined to be a pointer value that does *not* point to any object; at the same time STDIN_FILENO, denoting a file descriptor for standard input, has a value 0, which is equivalent to NULL. Since standard input cannot exist and not exist at the same time (quantum computers might change this...), the descriptor value cannot be a pointer. Interestingly, Unix file descriptors are *much safer* than standard C's FILE pointers in that they are free from undefined behavior. Of course, it would be even better to have a distinct type for them. (OK, that's enough for off-topic confusions, I duck away to reinvent My_Better.Text_IO on top of Ada.Streams ;-) ) -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: Dmitry A. Kazakov on 11 May 2010 04:26 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. A lexer routine shall never do that. You either read lines and then parse them, or else you do stream input and the line end is to be determined by the lexer (i.e. by the language being parsed). Here is the way I do it: http://www.dmitry-kazakov.de/ada/components.htm#Parsers_etc I never had any problems with line ends. > What you end up having to do is to > test for line number changes instead-- yuk. That is because you mix encoding and language lexis. Do not mix these two and everything will become simple. > In C, that is a feature. Yes, disaster is a C feature. (:-)) > So there was a technology change. That doesn't render the > C I/O system as a "disaster". If you want to say that you > "don't like it", then I can accept that. That's different ;-) OK, it was a technology change. We do not ride horses, we drive cars. So if anybody asks me to feed a beast, clean its droppings etc, it a disaster to me, a lazy, decadent man. Yes, I know, "real programmers do not use Pascal". (:-)) >>> C of course did >>> the same thing, except that they made formatting a string >>> easier. >> >> Easier? It is untyped! > > No, no, no "said the fish as he lit to the Cat in the Hat". > > You exaggerate. It is not strongly typed like Ada, but > by George, there are "types" in C. You can think of C > differentiating on the basis of "base" types. I meant formatted I/O. That is strictly untyped, not weakly typed. If you use dynamic lists of arguments, you have to be dynamically typed or else untyped. C chose the latter. > I just cited > one common and concrete formatting instance that gets > used in C frequently, that you cannot do in Ada "out > of the box". Luckily. As others already suggested, you should use type specific operations like "&" for that. Note that C++ chose that path too. I mean the operator <<. Surely there is a better way, that is what Ada stream I/O attributes are. Unfortunately they are hard-coded, because the language lacks multiple dispatch. So if Ada needed formatted I/O, there should be similar attributes, e.g. S'Format(Output, X), S'Scan(Output). But it does not worth the efforts. >>>> I wonder why people paying so much attention to >>>> admittedly broken and misplaced formatting of Ada.Text_IO in the >>>> times of GUIs. It won't work anyway. It is not a text anymore. >>> >>> Do you enter a picture when login to your favourite GUI >>> system? A wave file for your password? We still depend >>> a lot on Text. Look at any database- it's not all about >>> blobs. >> >> No, it is, for instance, about columned output of fixed point numbers >> in proportional font aligned along the decimal point... > > And what goes into that font drawing call? Text. No, strings + lots of commands. The point is that you do not need features like alignment and filling anymore. These were issues specific for computer peripherals of 50's-80's, when formatting instructions could be encoded as ASCII characters. It does not work anymore, unless you want to mess up with PCL, HTML, PostScript, XML, which are *languages*. > Yes, you > can mess with proportional fonts if you like, but it isn't > always that way. Nobody want to see fixed font output. > In fact, there are many instances where > proportional fonts are a curse. Only if the output is improperly formatted. There is no application for fixed point fonts other than for source code of a machine language. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 11 May 2010 04:35 On Mon, 10 May 2010 23:30:28 +0200, Ludovic Brenta wrote: > 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. It is a basis for creating inefficient time and space consuming programs. But we had this discussion before. >> 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)). I would like to add that "read a byte" is a property of a stream. Not all files ("everything") are streams. Stream is an interface to an object, which can be supported by the object or not. But if I have an object like text buffer, I want an interface of a text buffer, rather than of a stream. If the object is a data base, I want to stream it even less. The bottom line is, Ada does it right (tm). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: J-P. Rosen on 11 May 2010 05:49 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; -- --------------------------------------------------------- J-P. Rosen (rosen(a)adalog.fr) Visit Adalog's web site at http://www.adalog.fr
From: Maciej Sobczak on 11 May 2010 09:35
On 11 Maj, 10:35, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.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? Such an > >> operation is an important basis for custom buffered input. > > It is a basis for creating inefficient time and space consuming programs. > But we had this discussion before. No, we didn't. The discussion we had before was about buffered *output*, not input. Somebody called "Steve" jumped in and suggested that "Either you are miscommunicating or you are just plain wrong" (these words can be used to find that thread). Now we might have a different discussion about *input*. :-) OK, really - what's exactly being inefficient in buffered input? > I would like to add that "read a byte" is a property of a stream. Not all > files ("everything") are streams. I don't want to read all files. In particular, I don't want to read database files. 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. Oh, wait - we had that discussion already. ;-) > 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. With all due respect to some of the engineering pearls that are related to Ada, the standard Text_IO package sucks, terribly. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4 |