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: bobduff@world.std.com (Robert A Duff) Subject: Re: Shared Generic Instance Code Date: 1997/04/04 Message-ID: #1/1 X-Deja-AN: 230546973 References: <5hrkhkINN9ip@snoopy.cis.ohio-state.edu> <1997Apr1.201631.28634@ocsystems.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 1997-04-04T00:00:00+00:00 List-Id: In article , Bill Keen wrote: >In article , Robert Dewar >writes >> On the other hand, shared generics add a lot >>of complexity to a compiler. > >He also says Gnat does not share code between generic instances. > >But surely the mechanism for shared code is already there because of >dynamic instantiations like this. No, it's not *nearly* that simple. Yes, your example is sharing code between multiple (run-time) instances, but they're all essentially the same. That is, a macro-expanding implementation works just fine in this example (and yes, the expanded "macro" machine code might get invoked many times), and still generate just one copy of the code. Consider, for example: can you share code for "is new Text_IO.Integer_IO(Integer)" and "is new Text_IO.Integer_IO(Super_Long_Integer)", where Super_Long_Integer is range 0..2**1000, which might be accepted by some (mythical, unfortunately) implementation. >with text_io; >procedure p (x : integer) is > subtype T is integer range 0..x; > package Tio is new text_io.integer_io(T); >begin > Tio.put(0); >end; > >It cannot add complexity if it alredy exists. Sorry, but shared-code generics are far more complex than you imply here. - Bob