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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,24d7acf9b853aac8 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Path: g2news1.google.com!news4.google.com!feeder.news-service.com!85.214.198.2.MISMATCH!eternal-september.org!.POSTED!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: S-expression I/O in Ada Date: Sun, 01 Aug 2010 21:53:58 +0200 Organization: A noiseless patient Spider Message-ID: <8739uyw1m1.fsf@ludovic-brenta.org> References: <547afa6b-731e-475f-a7f2-eaefefb25861@k8g2000prh.googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Sun, 1 Aug 2010 19:54:07 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="vhtspQ5pQqftjY2c+x4BbQ"; logging-data="14725"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Rr+6mbVzSTvy+RjVlGmBx" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:Ju5N7zflBSiTvQNJxAq0FL+I3u4= sha1:Zg5bnc+uH/O2dwuBS+XHB+W155g= Xref: g2news1.google.com comp.lang.ada:12785 Date: 2010-08-01T21:53:58+02:00 List-Id: Natacha Kerensikova writes: > On Aug 1, 8:25 pm, Jeffrey Carter > wrote: >> You might very well be able to use something like: >> >> [snip] > > Thanks a lot for the example, it really looks like what I'm used to > (at least in C). > > I have to admit I don't really grasp the difference between the vector > you use and the Storage_Array, but it seems I have to research it by > myself before asking here. The vector manages its own memory, you can grow and shrink it at will. With a Storage_Array you must do that manually by allocating, reallocating and freeing as needed. >> If you can use unbounded strings as Brenta suggested, instead of an >> unbounded array of bytes (Storage_Element), then this would be even >> simpler. > > Actually I'm a bit reluctant to use Ada strings for atoms, because I'm > afraid it might somehow interpret the data (e.g. locale or encoding > related stuff, or trouble with NUL inherited from C). No, they won't. Ada does not need NUL since it has proper arrays. > I occasionally include binary data in S-expressions, and while I keep > it on the disk as a text file (using hexadecimal or base-64 encoding), > it is the S- expression library's responsibility to load it into > memory as the original binary data. I would still store the S-expressions in memory as Unbouded_Strings, read straight from the file (i.e. in the hexadecimal or base-64 encoding). Then I would provide conversion subprograms for each data type as needed on top of that. > On the other hand, most of my atoms are indeed strings, and Character > definition from A.1.35 looks exactly like a perfect mapping to bytes. > So if Ada strings have no issue with embedded NUL or non-graphics > character, and if binary data can be losslessly recovered once stored > into an Ada string, it could be the best type for atoms. It will > probably be a while before I reach the level of reading the Reference > Manual cover-to-cover, does anyone knows whether those "if"s are > guaranteed by the standard? While Ada strings indeed have no problems with embedded NULs or non-ASCII characters (the character set is Latin-1, not ASCII), it is unwise to use character strings to store things that are not characters. Like I said, you should see the character representation as the low-level (storage) representation, then provide conversion subprograms for the few non-String data types that you need. -- Ludovic Brenta.