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 13:05 Dmitry A. Kazakov expounded in news:h1uzhgbbx6hd.1lg6oydcub0re$.dlg(a)40tude.net: > 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). Empty lines are significant to my parser, when the basic programs are unnumbered. I'm not going to articulate why here, but they were significant. I will buy the argument that perhaps I should be using a stream input. But that'll wait for some other day, as I have much bigger fish to fry at the moment. >>>> 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. As I pointed out earlier, those *printf() arguments are checked, so it is not strictly untyped. You can lie to it of course.. >> 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. How does "&" fix the hexadecimal formatting? That is what I am discussing. > 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'm not complaining about that. I'm complaining that (for example) the hex conversion is "annoying" in that I have to "wrap it" to get my "proper" hex output. Ada gives me the hex, but a bunch of enclosing junk with it. >> Yes, you >> can mess with proportional fonts if you like, but it isn't >> always that way. > > Nobody want to see fixed font output. Pardon me? If you give me a report of my investment holdings with columns of numbers, then those numbers better line in columns as well. Have you ever put code in a Word document? You don't leave them proportional, do you? Gak!! > Only if the output is improperly formatted. There is no application > for fixed point fonts other than for source code of a machine > language. That's just wrong. See above for one more example. Warren
From: Warren on 11 May 2010 13:06 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". Warren
From: Dmitry A. Kazakov on 11 May 2010 13:15 On Tue, 11 May 2010 17:56:44 +0200, Yannick Duch�ne (Hibou57) wrote: > Le Tue, 11 May 2010 10:35:24 +0200, Dmitry A. Kazakov > <mailbox(a)dmitry-kazakov.de> a �crit: > >> 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. > Can you tell more please ? Buffering = making copies. A copy is always an overhead. It pays off if you have asynchronous components (use them in parallel), or components with high switching overhead, or faster memory (caching, indexing etc). If you don't have that it is just a loss. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Warren on 11 May 2010 13:17 =?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. But I do believe a POSIX friendly version of this should exist. Then the entire issue goes away. Under the hood, if the types work out the to the same size as a byte, you can capitalize on that in an implementation dependendant way. Anything that makes Ada more posix friendly, helps its general acceptance. Warren
From: Jeffrey R. Carter on 11 May 2010 13:38
On May 10, 1:52 pm, Warren <ve3...(a)gmail.com> wrote: > > 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. Did you save anything? Let me pull out my well worn copy of /Software Tools/, by Brian W. Kernighan and P. J. Plauger, Addison-Wesley, 1976. (Bear in mind that these are C guys.) "Most of the time programmers have no real idea where time is being consumed by a program. Consequently nearly all the effort expended (...) for 'efficiency' is wasted. We have found that the best way to avoid too-early optimization is to make a regular practice of in[s]trumenting code." "Algorithm and data structure changes are by far the most effective way to improve performance." The general rule is not to rewrite existing functionality unless your system does not meet its timing requirements with the existing operation, and measurement shows that the existing operation is causing the failure to meet the timing requirements. It is clear ("I didn't check") that this is not the case here. So, did you "save" anything? No, you not only didn't save anything, you wasted your effort by writing and testing code that duplicates existing functionality, that you were aware of, for no reason. |