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.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: Brian Rogoff Subject: Re: Any research putting c above ada? Date: 1997/05/21 Message-ID: #1/1 X-Deja-AN: 243536473 References: <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> <3380F4A5.1EBB@sprintmail.com> Newsgroups: comp.lang.ada Date: 1997-05-21T00:00:00+00:00 List-Id: On Mon, 19 May 1997, John G. Volan wrote: > Kevin Cline wrote: > > 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.) Same here. It is even possible to program at the same "low-level" as the C++ STL by using Interfaces.C. OTOH, I agree with Kevin Cline that the type inferencing done in C++ is convenient, and that a C++ programmer might find the long declarations troubling, especially for textbook examples where the length of the working code is close to the length of the declaration section. I suspect that this will be less of a problem in most real code. > 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. I'm "evolving" a version for my own use. I am trying to stay as close to the C++ STL as possible, but I've left out custom allocators (still experimenting) and I'm starting to diverge in that I'd prefer a more integrated approach to exceptions in the library, more like Cay Horstmann's Safe STL. The two languages and their respective programming cultures are different enough that the the design priorities in the source library (C++ STL) will differ a bit. One thing I wish I could do better is have the structure of Iterator categories reflected in the Ada code. In the STL, Forward_Iterators have properties of both Input_Iterators and Output_Iterators, i.e. generic type Value_Type is private; type Iterator_Type is private; with procedure Next ( i: in out Iterator_Type ) is <>; with function Get_Value ( i: in Iterator_Type ) return Value_Type is <>; package AGL.Input_Iterators is end AGL.Input_Iterators; generic type Value_Type is private; type Iterator_Type is private; with procedure Next ( i: in out Iterator_Type ) is <>; with procedure Set_Value ( I: in Iterator_Type; V: Value_Type) is <>; package AGL.Output_Iterators is end AGL.Output_Iterators; generic type Value_Type is private; type Iterator_Type is private; type Value_Ptr is access all Value_Type; with procedure Next ( I: in out Iterator_Type ) is <>; with function Get_Value ( I: in Iterator_Type ) return Value_Type is <>; with procedure Set_Value ( I: in Iterator_Type; V: Value_Type) is <>; with function Get_Pointer ( I: in Iterator_Type ) return Value_Ptr is <>; with function "="( I: Iterator_Type; J: Iterator_Type ) return Boolean is <>; package AGL.Forward_Iterators is end AGL.Forward_Iterators; Now, I could just define Forward_Iterators by having two generic package parameters, but then I'd have to instantiate an Input/Output Iterator pair every time I wanted a Forward_Iterators package. Right now I just leave this commonality in the documents, and express each Iterator independently. -- Brian