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/24 Message-ID: #1/1 X-Deja-AN: 243668073 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-24T00:00:00+00:00 List-Id: On 23 May 1997, Jon S Anthony wrote: > In article Brian Rogoff writes: > > 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). > > Really. Along the same lines, even if you were going to hack the > thing to look like the silly C++ implementation notion (address > arithmetic all over the place), they don't seem to realize that there > is (relatively) safe and standard support for this stuff: > System.Storage_Elements has all the address arithmetic they want and > System.Address_To_Access would let them to use 'Access for various > inputs. Correct. However, when they wrote that libary, existing implementations may not have had fully functioning versions of these packages. I know that their were lots of ugly parts of the library which were workarounds to GNAT 2.0x bugs; v3.09 compiles a much prettier library. > > I agree that the Ada approach to generics is superior, but the C++ > > approach is not without some advantages. I would question whether > > Right. As Richard O'Keefe has pointed out, the template language is a > computationally complete language - which happens to live inside > another such language (?!?!) - for which the template processor part > of a C++ compiler acts as a compile time evaluator. I missed Richard O'Keefe's post, but by now everyone has seen the C++ program which computes N! at compile time: template class Factorial { public: enum { fac = N * Factorial::fac }; }; class Factorial<1> { public: enum { fac = 1 }; }; I'm not arguing that such an approach is the right one to take for implementing genericity, but there are certainly neat template tricks you can play (if a C++ compiler would ever correctly implement templates :-) to get fast code. To do this in Ada, I suppose you'd have to write a macro language for Ada. -- Brian