From -4948710467129948338 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,e7ce30bc16218953 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-01-07 21:55:30 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!newspump.monmouth.com!newspeer.monmouth.com!newsfeed.icl.net!newsfeed.fjserv.net!colt.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: gp1@paradise.net.nz (Graeme Prentice) Newsgroups: comp.std.c++ Subject: Re: function template specialization deduction Date: Wed, 8 Jan 2003 05:55:25 +0000 (UTC) Lines: 75 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: mail2news.demon.co.uk 1042005325 15332 10.0.0.1 (8 Jan 2003 05:55:25 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Wed, 8 Jan 2003 05:55:25 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.05) id 18W9BT-0003yz-00 for mail2news@news.news.demon.net; Wed, 08 Jan 2003 05:55:24 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id QAA23193; Wed, 8 Jan 2003 16:55:15 +1100 (EST) X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Path: comp-std-cpp-robomod!not-for-mail X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-Delivered-To: std-c++@ncar.ucar.edu X-Newsgroups: comp.std.c++ X-Orig-NNTP-Posting-Host: 203-96-146-119.apx1.paradise.net.nz (203.96.146.119) X-Orig-X-Trace: fu-berlin.de 1041979718 16027483 203.96.146.119 (16 [98036]) X-Newsreader: Forte Agent 1.92/32.572 X-Spam-Status: No, hits=-7.1 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, SPAM_PHRASE_01_02 version=2.41 Xref: archiver1.google.com comp.std.c++:16886 On Tue, 7 Jan 2003 18:55:11 +0000 (UTC), nesotto@cs.auc.dk ("THORSTEN OTTOSEN") wrote: This is my second of two posts in this thread - I'm not sure which will turn up first but I think I got it wrong in my other post. <<<<<<<< copied from my other post >>>>>>>>>>>>>>> >My problem is then simply that cannot explain why >the latter version is a better >match than the first. I have tried looking at paragraph 13.3.3, 14.5.52 and >14.8.3 but could not find anything >that says that > >template< typename C, typename V > > inline void insert( C& c, const V& ); > >is a worse match than > > template< typename A > > inline void > insert( A& c, const typename A::container_type::value_type& v ); > >Is there some rule that "fewer template parameters is better" ? No, there isnt a rule that says that. The deduction process synthesizes a "unique type", "unique value" or "unique class template" and "calls" the other function When you synthesize a unique type for "A" (lets call it A) and substitute, you get insert( A& c, const typename A::container_type::value_type& v ); if you "call" the other function with these arguments, V will be deduced as A::container_type::value_type and the parameter types in the called function match the calling argument types exactly. When you do it the other way around, the calling types are insert( C&, const V&) the compiler now has to try to deduce the A in const A::container_type::value from the passed argument V - this fails because A::container_type::value does not have one of the forms listed in 14.8.2.4 para 9 Clearly, there's no possible way a compiler could work out the type of A for some arbitrary type V - this is mission impossible, so deduction fails hence the second function is more specialised than the first. <<<<<<<<<<<< end of copy from my other post >>>>>>>>>>>>>>> I have woken up to the fact that the call insert( C&, const V&) can deduce the type of A from the first parameter - so the fact that it can't deduce the type of A from the second parameter doesn't matter - most likely deduction fails because an arbitrary type C does not have a container_type member, or because V is not *exactly-the-same* type as C::container_type::value_type This looks like a complicated case and relying on the partial ordering rules to do what you hope doesn't seem like a good idea, even if you can figure out exactly why it does what it does. Graeme --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]