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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: Any research putting c above ada? Date: 1997/05/19 Message-ID: <3380F4A5.1EBB@sprintmail.com> X-Deja-AN: 242491583 References: <208C9C61CA05C32B.65D82DC950AAA33A.D68E7B27EB42E98A@library-proxy.airnews.net> <3372D44E.5F44@sprintmail.com> <337813DF.598C@dynamite.com.au> <337D3AE4.28F7@dynamite.com.au> <337E5854.1366@sprintmail.com> <12871CEBFAB00ABE.93483F73373D0261.D1086334F6EF8ED8@library-proxy.airnews.net> Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.ada Date: 1997-05-19T00:00:00+00:00 List-Id: Kevin Cline wrote: > > "John G. Volan" wrote: [referring to a "mutable" discriminated record with default constraint on the discriminant] > >Bottom line, if you declare one of these beasts in the ordinary way, > >your Ada compiler can certainly allocate it on the stack, and pass it > >back and forth on the stack. > > Of course, that's trivial to do, and extremely impractical if the object is > usually small but can occassionally be very large. Remember the original > problem that started this thread? Actually, no, sorry, jumped in late... > The poster claimed that it was easy to > write a program that read a file into an array of lines since Ada allowed > arrays of size determined at run-time to be returned as function values. > The I pointed out that: > > 1. Most files do not begin with a line count. That's certainly a ridiculous > requirement for manually prepared input. > > 2. Returning such an object is very inefficient because most compilers copy > the entire object. > > Now you tell me that variable-length arrays can easily be handled in Ada > without dynamic storage allocation. But then you indicate that the arrays are > not truly variable in size, but are restricted to a compiled-in maximum size. More precisely, they are, in fact, "variable" in size, but "bounded". I see now that you're looking for a solution that is "unbounded". The only alternatives are: (1) Use an "indefinite" type and return and instance on the stack (but this might involve extra copying): (a) The "indefinite" type could be an unconstrained array type, with the bounds on the actual instance not determined until runtime. (b) The "indefinite" type could be a discriminated record type (_without_ a default constraint), with the discriminant constraint on the instance not determined until runtime. (2) Develop an "unbounded" abstract data type (which, as you rightly assert, must entail using some kind of storage pool, perhaps the global "heap", perhaps some programmer-defined pool). > That's fine for embedded applications where the amount of data to be handled > is carefully defined ahead of time. It's useless for desk-top applications, > where the size of the data to be handled, and the physical resources available > to handle it vary widely from user to user. For those applications, you must > resort to truly dynamic data structures, and Ada's arrays are of little use. Of course, but what were you expecting? The semantic level of Ada95 is comparable to that of C++, and neither language was designed to include the kind of unbounded ADTs you're looking for -- at least, not as built-in features of the language. Rather, these languages provide the raw materials from which such ADTs might be constructed. A standard library might contain such examples as Ada.Strings.Unbounded in Ada95 and the STL in C++, but these components are _written in_ the given language, not _built into_ the language (i.e., implemented with compiler support). (Even in a language like Smalltalk, which routinely comes with unbounded ADTs such as sets, bags, ordered collections, and the like, these ADTs are not "built-in" any more than they are in Ada95 or C++. At least, not in the sense that a Smalltalk compiler knows anything about them. Rather, they're part of the standard class library, and are written _in_ Smalltalk.) > This is one of the biggest blind spots I observed in experienced Ada > programmers in a shop a few years ago. Ada programmers tend to use arrays > instead of more dynamic data structures, resulting in inefficient and > inflexible applications. This observation is not necessarily universal of all Ada programmers. > OTOH, I have observed that the availability of the > C++ STL containers is already expanding the toolkit of average C++ developers. There's nothing about the STL containers that couldn't be done in Ada95 -- probably much more simply, and thus, IMHO, better. (I myself have re-engineered the RBTree/Set/Map structures in Ada95 for my own purposes, it really wasn't very hard to get the basic functionality.) The advantange of the STL in C++ is that someone has gone to the trouble of working it up as a "standard" toolkit, and the general C++ user community is accepting it as such. It would be nice of someone could produce a comparable library of such tools in Ada95 and make them widely available. There's no technical obstacle to this, only an economic/cultural one: i.e., we need to get someone to actually do the work, and the Ada95 community needs to recognize the result as some kind of "standard," official or otherwise. ------------------------------------------------------------------------ Internet.Usenet.Put_Signature (Name => "John G. Volan", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: The World's *FIRST* International-Standard OOPL", Disclaimer => "These opinions were never defined, so using them " & "would be erroneous...or is that just nondeterministic now? :-) "); ------------------------------------------------------------------------