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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no 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!news4.google.com!news3.google.com!news.glorb.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)
Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng
User-Agent: 40tude_Dialog/2.0.14.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
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> <ow2Yd.21162$7U5.4617@fe04.lga>
 <opsnfw9nx75afhvo@localhost> <d0qiah$ep71@cui1.lmms.lmco.com>
 <pan.2005.03.11.18.01.45.684764@linuxchip.demon.co.uk.uk.uk>
 <d0sob3$3t5$1@s1.news.oleane.net>
 <4232ab3a$0$26547$9b4e6d93@newsread4.arcor-online.net>
 <pan.2005.03.14.14.41.47.813082@linuxchip.demon.co.uk.uk.uk>
 <d14co1$ca4$1@s1.news.oleane.net>
 <pan.2005.03.14.17.16.34.592520@linuxchip.demon.co.uk.uk.uk>
 <1110825790.396769@athnrd02>
 <pan.2005.03.14.19.27.46.488096@linuxchip.demon.co.uk.uk.uk>
Date: Mon, 14 Mar 2005 21:14:04 +0100
Message-ID: <1gf23j59mnsm2.wimnrcdrb09u.dlg@40tude.net>
NNTP-Posting-Date: 14 Mar 2005 21:14:04 MET
NNTP-Posting-Host: 46452a5b.newsread2.arcor-online.net
X-Trace: 
 DXC=e5c4:9]2CV33JZ<GaG=_E2Q5U85hF6f;4jW\KbG]kaM8liQbn6H@_E91ajCZd1=aL=WRXZ37ga[7:ncfD5BXcIX02mnGRdlDml9
X-Complaints-To: abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:9381 comp.lang.c++:45645
 comp.realtime:1463 comp.software-eng:5030
Date: 2005-03-14T21:14:04+01:00
List-Id: <comp.lang.ada>

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 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.  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!

It can be formulated in two words: "contract model" is what C++ templates
lack.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de