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: Dmitry A. Kazakov on 11 May 2010 13:54 On Tue, 11 May 2010 17:05:07 +0000 (UTC), Warren wrote: > 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, Then Get_Line is what you have to use. If the language is line-oriented, you read lines. If the language is character oriented, then lines do not exist. >> 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.. Which is precisely what being untyped is. BTW, printf is fundamentally uncheckable. Proof: char * Format = (HALT (p) ? "%d" : "%s"); printf (Format, 123); >>> 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. Oh, there are so many ways. E.g. 1. type Hex_Dump is new String; function "&" (Text : Hex_Dump; Value : Integer) return Hex_Dump; 2. type Formatted is private; -- Actually String function "&" (Text : String; Data : Formatted) return String; function "/" (Value : Integer; Base : Base_Number) return Formatted; "" & 2456/16 3. type Format_Int is record Value : Integer; Base : Base_Number; end record; function "&" (Text : String; Data : Format_Int) return String; "" & (2456, 16) I think you've got the idea. > 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. It is also annoying that I cannot output the number's base as subscript 16. Programming is generally annoying. I don't say that Ada's formatting is OK. Otherwise I would not write a formatting library of my own. I just don't consider formatting as an essential part of the language. Even at the standard library level it is not. >>> 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. Where is a problem? Fixed point is a relatively new invention, which came with computers. I have some old mathematical tables, they all use proportional fonts. Numbers are aligned on either of the margins. Fractional numbers are aligned on decimal point. > Have you ever put code in a Word document? You > don't leave them proportional, do you? Gak!! I meant this only case as a legitime use of fixed fonts. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 11 May 2010 13:59 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Yannick Duchêne (Hibou57) on 11 May 2010 14:19 Le Tue, 11 May 2010 19:38:44 +0200, Jeffrey R. Carter <ggsub(a)pragmada.x10hosting.com> a écrit: > "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." Sometime, I'm not aware of some terminology : did instrumented code (I don't like this word, âcodeâ, but don't bother) means âcode with which provide runtime statisticsâ ? -- pragma Asset ? Is that true ? Waaww... great
From: Yannick Duchêne (Hibou57) on 11 May 2010 14:48 Le Tue, 11 May 2010 19:15:07 +0200, Dmitry A. Kazakov <mailbox(a)dmitry-kazakov.de> a écrit: > 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. As yoi said, there is caching, and even the good old i486 did have a cache. If you are to iterate on the X coming items of data and X is not so much a big number (otherwise, you may iterate on multiple buffers), then you benefit from the cache, which is otherwise loose as soon as you call the method which will read one more items and which will load its own state into the cache. This is not so much special, near to all machines have a cache. Also, on a stream, you will need a cache if you are to walk forward in the data stream (a stream is one way only, always forward, not backward). As you were talking about checking that a particular optimization is really efficient or not, I can assert I've checked buffering improve performance on DOS running on i486 25 MHz. I remember of assembly or Pascal programs getting noticeably better performance as soon as they was relying on a buffer of at least 512 bits or more. There was a limit above which one increasing the buffer size was not increasing performance any more (if my mind is right, this was something like 2 Ki bytes) On another application I'm working on actually, on Windows XP running on a faster machine (1 GHz CPU), better performance can be gain with buffer size above the latter : I've check the application is consuming about 30% less times for execution with 150 Ki buffer than with a rather small one.. Giving it some even bigger buffer does not make so much difference. It seems to me the faster the machine is, the higher you can increase buffers size. Then, I feel you see copies where there are not more copies than with the way you suggest. Given this Read one byte in a one byte variable Read one byte in a one byte variable Read one byte in a one byte variable Read one byte in a one byte variable Read one byte in a one byte variable And then that Read five bytes in a five bytes buffer Which one do make more copies than the other ? The answer is None, they both copy exactly five bytes. The second one is not making more copy of anything, it is just using a bigger variable to store multiple items at once. So the matter then is âwhich is the best capacity for the bufferâ. First answer is âdepends on memoryâ (I'm not to say all memory may be used for that, just that there is a proportional relation) and the second answer is âcheck for it playing with buffer size and Ada.Calendarâ. There is also another point : it is mostly better, *when possible*, to do Batch OP1.1,OP1.2,OP1.3,OP1.4 Batch OP2.1,OP2.2,OP2.3,OP2.4 instead of OP1.1 OP2.1 OP1.2 OP2.2 etc ... The reason here again, is the CPU cache This is something which is a bit related to the ability of an application or an algorithm to be re-design on top of parallelism. Here, instead of getting benefit from simultaneous execution, we get benefit from CPU cache (and nearly to all CPU have a cache). Ah, an occasion to say the CPU cache also have another interesting effect peoples should know about : loop unroll is most of time anti-productive. If you enable the loop-unrolling âoptimizationâ option of your compiler, please, check this is really relevant, don't just believe it (by the way, code-cache and data-cache do not exactly apply the same strategy, so don't infer code-cache performance beliefs from data-cache performance observations). -- pragma Asset ? Is that true ? Waaww... great
From: Yannick Duchêne (Hibou57) on 11 May 2010 14:57
Le Tue, 11 May 2010 19:17:38 +0200, Warren <ve3wwg(a)gmail.com> a écrit: > All this is well and good for applications that can work in > "implementation defined" units of type Stream_Element. âImplementation definedâ here, means âplatform dependentâ. This is not âcompiler implementation dependentâ, this is âplatform implementation dependentâ. So this is not Ada's fault, nor this one or that one compiler implementation, this is just the real world. If you real world is never something else than file storage element of 8 bits, then the Assert pragma will never fail and that's all (you will even do not need the this Assert pragma at all, which is for greater trustability) > 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 ? > 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. Ada is POSIX friendly, and there are POSIX bindings to Ada, as well as an ISO standard for the POSIX Ada binding. You are formally wrong when you suggest Ada is not POSIX friendly. Ada will simply not be able to be POSIX friendly on platforms which are not POSIX. You know... even Windows XP Pro is very fat to be POSIX compliant ;) (to not talk about prior version of Windows) -- pragma Asset ? Is that true ? Waaww... great |