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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,f7c38a023cf370dc X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news3.google.com!feeder.news-service.com!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Should representation clauses be complete for each bit? Date: Wed, 20 Jul 2011 21:38:11 +0200 Organization: cbb software GmbH Message-ID: References: <73c10395-ec4f-4a02-b0fc-e35bc14424fa@e18g2000vbx.googlegroups.com> <17c212b1-d0a6-498a-a381-71188a67ec65@a10g2000yqn.googlegroups.com> <61e3eeed-23a0-47be-a18e-00684812204d@a10g2000yqn.googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: vkQ6fZYiCq6MIPSKHTx7gg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: g2news2.google.com comp.lang.ada:21218 Date: 2011-07-20T21:38:11+02:00 List-Id: On Wed, 20 Jul 2011 09:58:14 -0700 (PDT), okellogg wrote: > On Jul 20, 6:24�pm, "Dmitry A. Kazakov" > wrote: >> On Wed, 20 Jul 2011 08:29:18 -0700 (PDT), okellogg wrote: >>> My use case originates from a bit packed communication protocol where >>> the standard requires spare bits interspersed among the useful data. >> >> My advise would be not to use representation clauses. They cannot deal with >> protocols anyway. > > Wow. I thought this is what rep clauses are there for. I doubt it. Theoretically one could invent some data representation language capable to match and parse a protocol into a set of typed objects. Ada's representation clauses is not such a language being too limited and too primitive. I think Ada designers didn't considered this as a goal, because they didn't bother to provide representation clauses for floating-point types, variant records, unconstrained arrays, linked lists etc, the types you really need to map any, more or less, elaborated protocol. Even if they did, that would be still useless, without the notion of state influencing the representation etc. >> Think about protocol error handling, special patterns of >> bits, checksums etc. It also makes no sense in letting the wire-specific >> types to spoil the rest of your code with unchecked unions, nonnative >> scalars, misaligned data, nul-terminated rubbish etc. Any performance gain >> compared to explicit parsing would be negligible and may turn to a loss >> later when the data are used. > > Mind you, I am talking in hindsight, this is not something I invented. > I.e. I've implemented the mentioned protocol already. OK, you were lucky, or maybe not, because it may have hit you later. > I share your concerns wrt a high level interface but I'm talking about > a driver API here. What is the difference? > At this level, the user must know precisely what he's doing anyway, > and that filling data into spare fields isn't going to buy anything. > It's just extra baggage that nobody really needs. Poorly designed protocols are more common than others. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de