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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!newscon02.news.prodigy.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada) Date: 14 Mar 2005 16:02:43 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <42309456$1@news.broadpark.no> <4232ab3a$0$26547$9b4e6d93@newsread4.arcor-online.net> <1110825790.396769@athnrd02> <1gf23j59mnsm2.wimnrcdrb09u.dlg@40tude.net> NNTP-Posting-Host: shell01-e.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1110834165 18656 69.38.147.31 (14 Mar 2005 21:02:45 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Mon, 14 Mar 2005 21:02:45 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:9394 comp.lang.c++:45668 comp.realtime:1475 comp.software-eng:5041 Date: 2005-03-14T16:02:43-05:00 List-Id: "Dmitry A. Kazakov" writes: > On Mon, 14 Mar 2005 19:29:25 GMT, Dr. Adrian Wrigley wrote: > > > On Mon, 14 Mar 2005 20:43:08 +0200, Ioannis Vranos wrote: > > > >> Dr. Adrian Wrigley wrote: > >> > >>> the problem as I suggested in my previous post is that you have to > >>> pass in the comparison operator or hash function down the tree > >>> of template/generic instantiation, (composing them along the way) > >>> if you want to use maps/hashes. > >> > >> In the standard library containers and algorithms case you do not pass > >> any function to the container. operator< is implicitly used. The fact that "<" can be implicitly passed to the template/generic (in C++/Ada) is not relevant; Dr. Wrigley's point is that it has to be there. > > The comparison operator here seems to be a generic formal function > > parameter with a default value. This must be available at instantiation. > > The operator becomes part of the interface (implicitly or explicitly) for > > any code instantiating the std::map. Where does the code for the > > comparison operator go? It *has* to go at the point the class > > is defined. Because the "<" (or Hash) needs to know the internals of the thing. In other words, at the point where you declare a type, you have to think ahead: this type might want to live inside one of those containers, so I'd better define the necessary operations. I agree -- that's a pain. The only way around it, it seems to me, is to have the compiler automatically create a hash function (or something) for every type -- after all, you can't expect to create these kinds of containers without a hash function (or something, like "<"), whether the user is required to write it or not. Lots of languages do something like that, but I don't know of any such that emphasize efficiency like C++ and Ada. Also, in the "<" case, the "<" might mean something important (so you can iterate through the container in a sensible order), and I don't see how the compiler can be expected to guess what order that is. > > ...This could be at the other end of a hierarchy of > > generic instantiations. The result is that the implementation > > requirement (needs a comparison operator) has propagated up the > > generic hierarchy to some otherwise completely independent code as an > > interface requirement. I'm sorry I can't explain this any better! I think I understand what you mean. > It can be formulated in two words: "contract model" is what C++ templates > lack. Which is both a benefit and a drawback. C++ templates are somewhat more powerful that Ada generics, because of the lack of contract model, and implicit instantiation. But I don't think that addresses Dr. Wrigley's complaint (which applies to both Ada and C++). - Bob