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,37680a99b5e22b2b X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Shared Generic Instance Code Date: 1997/04/02 Message-ID: #1/1 X-Deja-AN: 230148774 References: <5hrkhkINN9ip@snoopy.cis.ohio-state.edu> <1997Apr1.201631.28634@ocsystems.com> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-04-02T00:00:00+00:00 List-Id: Joel says <. That's certainly a valid point. On the other hand, shared generics add a lot of complexity to a compiler. There is also a problem of patents. DEC holds patents on the implementation of shared generics which make it less worth while to investigate this approach. A programmer definitely has to be aware of whether generics are shared or not. In most compilers, generics are not shared (Rational and RR are notable exceptions, and the DEC 83 compiler also does a fairly complete job of generic sharing -- see above note on patents). If generics are NOT shared, then you want to factor generic and non-generic code as much as possible. Have a look at how Integer_IO is done in GNAt to see an example of this in action. Back to debugging: it is tricky to deal with non-shared generic instances in debuggers. In GNAT we have the first step, the compiler fully understands source locations with respect to generics (you can see that from the error messages, which pinpoint the template and instantiation locations). We are working now on passing this information through to GDB, and have some interesting ideas on how this might be done. Robert Dewar Ada Core Technologies