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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,47bc849aad30d586 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-01 05:14:32 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!newsfeed.icl.net!opentransit.net!fr.clara.net!heighliner.fr.clara.net!news-x2.support.nl!psinet-eu-nl!psiuk-p4!uknet!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: A standard package for config files is needed Date: Fri, 31 May 2002 13:25:31 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: References: <3CF5D7AC.975B0DB3@cs.tu-berlin.de> <4519e058.0205310825.868fe4a@posting.google.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1022865933 8866 136.170.200.133 (31 May 2002 17:25:33 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 31 May 2002 17:25:33 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:25146 Date: 2002-05-31T17:25:33+00:00 List-Id: "Ted Dennison" wrote in message news:4519e058.0205310825.868fe4a@posting.google.com... > > No its not. There's nothing in the Ada standard that says the data > written out to streams has to be portable, or even what its format is > at all. I think the order subobjects of compound structures get > written out is specified, but that's about it. Configuration files > generated via this method will not work with another compiler, will > probably not work on another platform, and are not even guaranteed to > work with *the same* compiler after an upgrade (unless your vendor > cares to give you that guarantee). > Sorry. I didn't mean that the *file* would be portable. I meant that the *code* would be portable. It would use no features outside of the standard Ada language. (Unlike, say connecting to the Win32API to get all the information from the registry.) I just don't see file portability being that big an issue. Certainly not any more important than the fact that there is no guaranteed portability of anything you create with any of the other I/O packages. > Also realise that for many programs, developing their own tools to > allow users to change the settings would be a real pain. Not every > program is an interactive GUI app. > Sure, but if the protocol is for the app to establish default values on startup for anything that is missing and then to save values as user's change things in the app, it wouldn't be a big deal. This isn't the sort of thing to use for a massive database - just a relative handful of things that a program needs to remember between executions. > With a text file you can lay all the options out there for the user, > and even add comments to explain *why* the settings were put where > they currently are. You can't easily do that with a program > (particuarly an embeded or real-time app with no user interface). > But in an embedded, realtime app, I seldom have Text_IO anyway. :-) Here, I'd be better off with a Stream that I could somehow write into NVRAM, rather than rely on a file system that maybe doesn't exist. I'm suggesting that a Stream oriented load/store would get the whole thing *started* and then these load/store operations could be overriden by child packages that might support a whole range of different options. Build the AdaINIRegistry as a tagged record with the right methods that hide the mechanism for storage and it is easily changed for different situations. As a matter of fact, the OO strategy would give you the natural means of doing default initialization of the registry because you could derive from the root and the "Load" checks to see that something is present for the app-dependent entries. If not, it creates them. Hmmm..... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com