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: STL in Ada95 [was: Any research putting c above ada?] Date: 1997/05/22 Message-ID: #1/1 X-Deja-AN: 243186931 References: <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> <33838C37.29C0@sprintmail.com> Newsgroups: comp.lang.ada Date: 1997-05-22T00:00:00+00:00 List-Id: On Wed, 21 May 1997, John G. Volan wrote: > Brian Rogoff wrote: > > Same here. It is even possible to program at the same "low-level" as the > > C++ STL by using Interfaces.C. > > Nah...why bother? I'd rather provide a Size_Type and whatnot as generic > formal parameters, rather than kludge in a lot of > implementation-dependent details. That is exactly what I do in my implementation of Random_Access_Iterators. In the RPI implementation, Interfaces.C types pollute the generic signature for Random_Access_Iterators, now I have a clean signature that still works with their low level Vectors (which also use ptrdiff_t's all over). > > > 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. > > I suppose you're talking about all those generic algorithms (template > functions) in the STL. Shrug. Personally, I'd rather _know_ what > instantiations are being linked into my program, than have them all be > implicit. Goes back to the easy-to-write vs. > easy-to-read/understand/debug issue between C++ and Ada95. I agree that the Ada approach to generics is superior, but the C++ approach is not without some advantages. I would question whether the Ada approach is any easier to read in this case; more verbose doesn't translate to more readable. > > 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) > > I assume you mean passing a Storage_Pool as a generic formal parameter > into a container generic package. Might be nice to have, but I wouldn't > bother for a first cut. Personally, I'm a little mystified about all > those contortions the STL had to go into about allocators. All that > stuff about distinguishing pointers as NEAR vs. FAR vs. HUGE -- is that > just a peculiarity of doing C on the Wintel platform, or is that a > platform-independent peculiarity of C programming? :-) That is a Wintel thang. > > 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. > > Hmm, sounds interesting... is there a URL for that? Jump point for STL stuff : http://www.sgi.com/Technology/STL/ Safe STL : http://www.horstmann.com/safestl.html -- Brian