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,c469fdacc2f3302b X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder.news-service.com!188.40.43.213.MISMATCH!feeder.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Warren Newsgroups: comp.lang.ada Subject: Re: Dynamic Variant Record Creation Date: Tue, 16 Mar 2010 20:59:53 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Tue, 16 Mar 2010 20:59:53 +0000 (UTC) Injection-Info: feeder.eternal-september.org; posting-host="9f8M0iN5t54V+4DF/iqO8g"; logging-data="20930"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18nY0a0+Nrb/5KGJtmW2nGLTL3uWhDX2Po=" User-Agent: Xnews/5.04.25 X-Face: &6@]C2>ZS=NM|HE-^zWuryN#Z/2_.s9E|G&~DRi|sav9{E}XQJb*\_>=a5"q]\%A;5}LKP][1mA{gZ,Q!j Cancel-Lock: sha1:ruTNJioSuXCE1xLTNbDiL4+pvbo= Xref: g2news2.google.com comp.lang.ada:10582 Date: 2010-03-16T20:59:53+00:00 List-Id: Robert A Duff expounded in news:wccljdsnh48.fsf@shell01.TheWorld.com: > Warren writes: >>...I am simply laying out a "problem" and looking for a >> suitable "solution". > > Sure. It's a real problem. I've run into it myself. The other way for me to solve this is simply provide a discrimanant that only identifies the few variants. But to keep to 32-bits, I'd have to find a way to specify the discriminant as 3-bits, which I don't think is possible. I'm thinking of bitwise layouts like (random example): for DeviceDetails use record at mod 2; status at 0 range 0 .. 7; rd_stat at 1 range 0 .. 3; wr_stat at 1 range 4 .. 7; end record; except that the discriminant also be described somehow as 3-bits. > I don't see it either. My guess is it involves creating an object > constrained to the right discriminant, without using an > aggregate. I see it now.. yes, same idea. >> I wasn't looking for compiler-implementation/language amendments. >> Just looking for good advice on how others would takle this problem. >> Perhaps the full case statement is the right way, but I gotta say >> that it puts a damper on readability. > > One solution is to write the aggregates out at each place. No, that won't work because after I have an "identifier", I look it up in keyword (and function name) tables. Once it is recognized as a keyword, LEX_IDENT is replaced with the returned specific keyword id. This simplifies the parser pass later. The character case, is an "others =>" case. Once completed, there will not be many aside from the usual single operators, brackets, comma and colon etc. There's just enough there to be a nuisance. > You said you wanted efficiency. Well, this: > > T : Token_Type := Token_Type'Val(Character'Pos(Ch)); > > is unlikely to be efficient. The case statement will be better > in that regard. If true, I'd like to know why. I can't see that in the compiled code being much other than a move short. If I get time tonight, I'll investigate it. > Another solution is to make the record non-variant. > Store Func and Id in the same component, and use > whatever conversions you need. Wrap this in accessor > functions. Ya, or I could use a 2005 union perhaps. I'm just trying to keep overhead down and safety "up". This is an experimental rewrite of a C project of mine. Warren