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,56525db28240414a X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.66.76.162 with SMTP id l2mr2524997paw.42.1343789445531; Tue, 31 Jul 2012 19:50:45 -0700 (PDT) Path: p10ni7591933pbh.1!nntp.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Efficient Sequential Access to Arrays Date: Sat, 28 Jul 2012 09:37:30 +0200 Organization: cbb software GmbH Message-ID: <1tcosruz32van$.1wcucid7mxne2$.dlg@40tude.net> References: <01983f1c-f842-4b1f-a180-bcef531dad4c@googlegroups.com> <87ipdf4vh6.fsf@mid.deneb.enyo.de> <4ce44d2d-d789-42a0-a6ed-035f7f8d58be@googlegroups.com> <1d20andzhb0rk.ytxhpkza8tky$.dlg@40tude.net> <1qlao21lvhn4q.p95zkkqzzcqz$.dlg@40tude.net> <802f6aec-a448-4a41-8320-fbdb5ffa7883@googlegroups.com> <1lqose2aygd4r$.ots4i45o7jnz.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 9A8bJrx4NhDLcSmbrb6AdA.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Received-Bytes: 4214 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2012-07-28T09:37:30+02:00 List-Id: On Fri, 27 Jul 2012 22:32:15 -0700 (PDT), Shark8 wrote: >>>> These assumptions must be upheld per value construction. >>> >>> Er, yes? Your value-construction procedure, which might be a >>> stream-implementation, could use 'Input to ensure the data is valid, no? >>> Then isn't the 'Read the value-construction? >> >>Neither. If you use stream you should do it properly, i.e. as the transport >>layer. The transport is defined in terms of bytes, characters or other >>units. So the only read here might be Character'Read. > > Um, I think you completely misread what I was saying. You can use 'Read > and 'Write to handle your import/export to the requisite format; the > 'Write shouldn't be an issue (WRT validity; at this point your object > should be valid and your writing it out should be straightforward), No, Write is like as Read. It must be validated against the prescribed format of the stream. Nothing in Ada standard mandates that. E.g. you take the protocol which tells you that the number to be in the "Motorola representation", 2 octets, range so and so, that describes some non-Ada type to which your application type need to be converted, explicitly. Usually it is bounds which make most work. Because sending an out-of-range value might in some cases severely damage the device. Though I remember a case when the communication protocol used IEEE 754 and the problem was with non-numbers, like NaN. It is also not so uncommon that some integer values have a reserved meaning. E.g. 16#FFFF# might mean "start calibration procedure", rather than +10V. >'Valid might be a perfectly reasonable way to raise an exception; as I > said before many DBs do not have ranges on their values; if your data (say > for a simulation) is exported to a DB, then any import needs to check that > the constraints on the fields [present in the program, not present in the > DB] have not been broken. (A common cause would be because of some SQL > update-statement some user ran.) Why would using 'Valid be the wrong way > to go if those constraints were strictly subranges? As I said, what you describe is a wrong pattern of implementation communication with an external party. The proper pattern, I think I described it already, does not require 'Valid. BTW, when you talk about constraints, that let me suggest another problem you have. You seem to use same numeric type for many things. In Ada it is considered good practice to declare many disparate types rather than subtypes of Integer. This is "weak" vs. "strong" typing POV. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de