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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c5fe2cecfab19751 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-11 09:36:50 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!eusc.inter.net!cs.tu-berlin.de!uni-duisburg.de!not-for-mail From: Georg Bauhaus Newsgroups: comp.lang.ada Subject: Re: limited types in libraries Date: Thu, 11 Dec 2003 17:36:48 +0000 (UTC) Organization: GMUGHDU Message-ID: References: NNTP-Posting-Host: l1-hrz.uni-duisburg.de X-Trace: a1-hrz.uni-duisburg.de 1071164208 18970 134.91.1.34 (11 Dec 2003 17:36:48 GMT) X-Complaints-To: usenet@news.uni-duisburg.de NNTP-Posting-Date: Thu, 11 Dec 2003 17:36:48 +0000 (UTC) User-Agent: tin/1.5.8-20010221 ("Blue Water") (UNIX) (HP-UX/B.11.00 (9000/800)) Xref: archiver1.google.com comp.lang.ada:3390 Date: 2003-12-11T17:36:48+00:00 List-Id: ada_wizard@toadmail.com wrote: : Georg Bauhaus writes: : :> Sometimes I dearly wanted limited records but was defeated :> by the library that could not store them (storing them was the :> intention): :> :> type T(x: access D) is tagged limited private; :> :> I want x to be constant plus initialised once and for all, :> so access discriminants are just fine, but T has to :> be limited then. Which would have been o.K., but not every library :> allows this. : : Just use the libraries that do; that's why there are more than one! What I'm doing is I'm using several, for some reaons, currently in seperate configurations. One reason is that at the current (early) stage it helps me think about what data I have, and how they interact, independent of the implicit "design hints" that a library might entail. Then there are the features and functions I need, and while the offerings are rich, they are not equal so some work needs to be done anyway. Once you know a few bits about how STL works, working with Charles is straight forward, and a lot is there, but not everything. As the author says, it isn't completely done, and so occasionally I stumble (for example assigning maps and then using iterators (assignment was done in error, but still)). BCs have graph support in a manner that fits parts of my program very nicely. So, I can use Charles containers for representing graphs, and I can use BC's graphs directly. Both libraries have iterators, so implementation of algorithms can be similar. Then I want the libraries to be as invisible as can be, in particluar they are banned from specs other than (my own program's) *.Support.* packages. :> What should I do? : : If the libraries that do allow limited items don't provide the : functionality you need, help add it. Difficult, see below. : Or, talk to the authors of the libraries that don't allow limited : items, but do offer the functions you want, about improving them. If I had the money, I'd be glad give it to someone :-/ (From what I see, there might be a few things to consider when a container is to be used with limited types. If you want to reuse code from the "non-limited" container, how does a "non-limited" container implmentation depend on comparison and assignment of the element type (and key type, possibly). What does it mean if a user supplied comparison function does not fulfill a non-language requirement? (I think in Charles it turns out to be a programmer's problem if he/she does not implement "=" and "<" in a consistent manner for element/key. (That is also true for STL's equivalents, IIRC.))) : SAL (http://www.toadmail.com/~ada_wizard/) allows limited items, but : is somewhat lacking in functionality compared to other libraries; want : to help improve it? Improving container libraries looks like really hard and admirable skillful work, therefore I don't feel like I can be of great help. (Let alone time...) For example, when I ran into the above mentioned Iterator problem when copying a (sorted) map, I found myself following paths deep down into a red-black tree (implemented following the first edition of Corman/Leiserson/Rivest is seems) and wondering why some pointer was null, until I thought I had discovered that Assign (I think) had not been done yet, it is commented. Luckily I shouldn't have used assignment in the first place, so this has actually helped me discover a "design bug" in my program :-) However, to solve these kinds of problems in a library it takes a programmer with more skills than I will every have, I'm afraid. But I will look at SAL (and the PragmARCs) when the program has been assembled from its working pieces (in Charles and BC configurations), in a second iteration to see whether the specs are sufficiently abstract to allow an exchange of components. I'll do that until there is a sufficient guarantee that some library/ies will be provides with Ada :-) -- Georg