From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,cfb2002511b830ab X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.59.229 with SMTP id c5mr26778298pbr.6.1322500780495; Mon, 28 Nov 2011 09:19:40 -0800 (PST) Path: lh20ni31397pbb.0!nntp.google.com!news1.google.com!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: Starter project: getopt_long in Ada Date: Mon, 28 Nov 2011 17:18:18 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <4ecfc4c4$0$6579$9b4e6d93@newsspool3.arcor-online.net> <4ed3ad98$0$6573$9b4e6d93@newsspool3.arcor-online.net> Mime-Version: 1.0 Injection-Date: Mon, 28 Nov 2011 17:18:18 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="Mda950WjNwNLAFOE7yJXQw"; logging-data="22307"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Hxa9TVwIjRTuKiAHtkfsU" User-Agent: slrn/0.9.9p1 (FreeBSD) Cancel-Lock: sha1:Ob1twuThlX7NMZppzydVAZCHxCI= Xref: news1.google.com comp.lang.ada:19218 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: 2011-11-28T17:18:18+00:00 List-Id: On 2011-11-28, Georg Bauhaus wrote: > On 26.11.11 19:13, Natasha Kerensikova wrote: >> While I certainly agree with this in general, in this particular case >> I'm skeptical about (2), since I can't think of any example where error >> handlers are not fatal, which leaves only one handler that only has to >> communicate with itself. > > Two use cases for stateful handlers that I can think of are > > 1) -v -v ... increasing verbosity, i.e., handling means counting > the number of times an option has occured > > 2) Two options -A and -B must not occur ensemble, in any order or > frequency (This is "inspired" by really complicated setups, such > as the nightmarish command line interface of ffmpeg.) > > In either case, the handlers would have to have a way to be > informed about prior occurrences. I think we had a bit of a misunderstanding about the word "state". My point was that I couldn't (and still can't) think of any example where an *internal* state for handlers is needed. Of course, command-line flags have to change something, otherwise it's useless to parse them, but they change a *global* state. Or at least an externally-visible state, if you prefer to query a global object rather than have a collection of global variables (I prefer releasing everything related to argument parsing before starting the actual processing, but that's a personal taste.) The verbosity level is most likely an integer, conceptually in a global state (even if it's hidden behind a function rather than in a global variable), and -v handler only communicates with the global state. For case 2 it's a bit more difficult to answer, it depends on the rest of the design, whether the handler launches some actual processing or only record the arguments in a friendlier format to be executed at some later point. Anyway, we actually agree on the necessity to have a state, and I admit I didn't think of the possibly of having the parsing object (whose dispatching subprograms replace the current access-to-subprograms) be also a holder for the global state. > Do not worry about efficiency of indirect calls. To be honest I really don't. Especially since we were talking about command-line argument parsing, which is seldom a performance-critical piece of code. And the difference cannot really be worse than an extra dererefence/memory access, which is also negligible is most situation even when performance matters. It might be significant for memory-constrained devices, but I've never come close to any such device (even though I would love to). > For illustration, in traditional Ada, one may pass a callback as a > generic formal subprogram. There is then no pointer. The following example > is from a translation with optimization turned on, but without any inlining > and checks turned off: > > using a procedure pointer: > > 0: 55 push %ebp > 1: 89 e5 mov %esp,%ebp > 3: 83 ec 08 sub $0x8,%esp > 6: c7 04 24 01 00 00 00 movl $0x1,(%esp) > d: ff d0 call *%eax > f: c9 leave > 10: c3 ret > > using a formal generic procedure: > > 30: 55 push %ebp > 31: 89 e5 mov %esp,%ebp > 33: 83 ec 04 sub $0x4,%esp > 36: c7 04 24 02 00 00 00 movl $0x2,(%esp) > 3d: e8 de ff ff ff call 20 > 42: c9 leave > 43: c3 ret > > Don't know if there is a difference at all in terms of > efficiency. I would be quite confident there is no difference between these snippets on 21st century i386 processors. What does make a difference, although probably small, is that in the first case an address has to somehow end up in eax, while the second has a ready-to-use constant. I would guess that the address in eax is loaded from memory (hence the extra dereference/memory access I keep mentioning), or maybe somehow computed. And that's the efficiency difference between both situations. > If you remember that a discriminant acts a a subtype > constraint, your worries might be fewer: Once the constraint > has a value, the value will suitably restrict the set of > possible values of the type. This might also mean > that operations can now select specific behavior depending > on the discriminant constraint. This constrains the set > of possible behaviors. I will have to think deeper about it. Right now I'm mostly realizing that I have no idea how discriminants and type expansion in interact: can I expand a constrained root? Or do I have to constrain the instance of the derived type? And few other considerations like that. It looks like it's time to stop writing and go reading for a while. Thanks a lot for the pointers, Natasha