From 4874090589217729195 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,3b5faa9aaea18095 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2003-10-02 15:15:03 PST Path: archiver1.google.com!news2.google.com!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!elnk-nf2-pas!elnk-pas-nf1!newsfeed.earthlink.net!west.cox.net!east.cox.net!peer01.cox.net!cox.net!kibo.news.demon.net!mutlu.news.demon.net!demon!mail2news.demon.co.uk!devnull From: deepblue57x@yahoo.co.nz (Graeme Prentice) Newsgroups: comp.std.c++ Subject: Re: Problem with function template overload resolution Date: Thu, 2 Oct 2003 22:14:59 +0000 (UTC) Lines: 241 Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <4e6fccc6.0309162227.1aa4bda7@posting.google.com> <3F6E975F.8050300@grad.hr> <4e6fccc6.0309231302.4c6a4a9f@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: mail2news.demon.co.uk 1065132899 20201 10.0.0.1 (2 Oct 2003 22:14:59 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 2 Oct 2003 22:14:59 +0000 (UTC) X-Received: from mulga.cs.mu.oz.au ([128.250.1.22]) by news.demon.co.uk with esmtp (Exim 4.12) id 1A5Bir-0005Ff-00 for mail2news@news.news.demon.net; Thu, 02 Oct 2003 22:14:58 +0000 X-Received: from localhost (localhost [[UNIX: localhost]]) by mulga.cs.mu.OZ.AU id IAA19524; Fri, 3 Oct 2003 08:14:54 +1000 (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++@ucar.edu X-Newsgroups: comp.std.c++ X-Orig-NNTP-Posting-Host: 203-96-146-120.apx1.paradise.net.nz (203.96.146.120) X-Orig-X-Trace: news.uni-berlin.de 1065086526 12469711 203.96.146.120 (16 [98036]) X-Newsreader: Forte Agent 1.93/32.576 English (American) X-Spam-Status: No, hits=0.7 required=5.0 tests=HTML_00_10,REFERENCES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.cs.mu.OZ.AU id IAA19524 Xref: archiver1.google.com comp.std.c++:22 On Wed, 1 Oct 2003 15:53:53 +0000 (UTC), Patrick.Kowalzick@cern.ch ("Patrick Kowalzick") wrote: >Hello Graeme, > >I think I did not express me correct , yesterday. Sorry for that. I do n= ot >doubt your explanation of the standard, but I have some problems >understanding it. ok, I didn't understand your previous post. [snip] > >OK, I agree but I try to construct a new example, where the first foo >accepts only a special type. (without any interpretation: bcc32 and g++ = do >not compile, MSCV does) You could also try http://www.comeaucomputing.com/tryitout/ where the Comeau 4.3.3 beta version can be used to compile code snippets online for free. (or you can buy the compiler for U.S. $50) > >// ***** CODE starts ***** >#include > >class arg_1 {}; >class arg_2 {}; > >template void foo(const arg_1&) >{ > std::cout << "foo" << std::endl; >} > >template void foo(const A&) >{ > std::cout << "foo" << std::endl; >} > > >int main() { > > foo < arg_1 > ( arg_1() ); > foo < arg_2 > ( arg_2() ); > foo < arg_1 > ( arg_2() ); > foo < arg_2 > ( arg_1() ); > > foo< arg_1 , arg_1 > ( arg_1() ); > foo< arg_2 , arg_1 > ( arg_1() ); > >} > >// ***** CODE ends ***** > >Now I try to follow the logic to determine the specialization: -first fo= o() >is taking U, calls second with foo(U) which fails because there is no >possibility to deduct the second type.=20 Close but not quite right - the partial ordering process says that you synthesize a set of unique types (or values, or templates) for the template parameters and substitute them into the function parameters - so for the first foo, synthesize a type U for parameter A and substitute into the function parameter (const arg_1&) - since A doesn't appear in the function parameter anywhere, you are left with const arg_1& as the type of the argument used to make the call to the second foo(). Deduction then fails because the type of the template parameter R in the second foo cannot be deduced as you say. > -second foo() is taking U, calls >first with foo(U) which fails because arg_1 is expected. That's close too - but type of the argument in the call is const U& and deduction fails as you say because arg_1 is expected. > >This means, neither first nor second foo is more specialized and the cal= l >foo(arg_1()) may not work. >(I hope I am right until here otherwise do not read the rest ;-) , which >means g++ and bcc32 are perfectly right as well) That's correct. > >But me personally would assume the same rules for overloading like the o= nes >for not templated functions and just take the first one, because arg_1 i= s >the parameter which is passed. Yes, if you didn't know the intricate rules, that would be the intuitive choice. >I found this in >"14.8.3 Overload Resolution >[snip] >The complete set of candidate functions includes all the function templa= tes >instantiated in this way ann all of the non-template overload functions = of >the same name. The function template specializations are treated like an= y >other functions in the remainder of overload resolution,..." Yes, you also need to look at 13.3.3 para 1 for overload resolution. [snip] >Here I mean: >I do not understand why to compare the calls foo(U) if the calls foo(= U) >are causing troubles. Would it be more clear if it is >"Giving two overloaded function template SPECIALIZATIONS...." >? In the sense of >"14.8 >Aa function instantiated from a function template is called a function >template specialization;" Yes - it's usually just called a "specialisation". The book "C++ Templates The Complete Guide" by Vandevoord and Josuttis devote a whole appendix to this topic (overload resolution). To understand what I write (and quote) below, you need to understand some terminology. This is a (primary) "function template" template void foo( const A& ) { // ... } This is an explicit specialisation template <> void foo( const int& ) { // ... } If I call the function foo like this ... foo( arg_1() ) then the compiler generates a "specialisation" of the "function template" with arg_1 as A. Note how I emphasize the term "function template". The term "primary" is also used in relation to templates - a "function template" is also a primary template. In the class of class templates, the term primary is used to distinguish between class partial specialisation templates (which are not primary templates) and the class template that it specialises. In the case of function templates, there is no partial specialisation so a function template is always a primary function template (currently). An explicit specialization is NOT a function template. Now back to overload resolution. Here's a quote from 13.3.3 (with some of the TC1 corrections applied) < quote C++ std 13.3.3 para 1, bullets 3,4,5> Given these definitions, a viable function F1 is defined to be a better function than another viable function F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then=20 =97 for some argument j, ICSj(F1) is a better conversion sequence than ICSj(F2), or, if not that,=20 =97 F1 is a nontemplate function and F2 is a function template specialization, or, if not that,=20 =97 F1 and F2 are function template specializations, and the function template for F1 is more specialized than the template for F2 according to the partial ordering rules described in 14.5.5.2, or, if not that, Overload resolution works roughly like this ... 1. First an overload set is formed by finding all "visible" functions that match the function name. This includes function templates but does NOT include explicit specializations of function templates. 2. A set of viable functions is formed (13.3.2) - functions are eliminated from the overload set if they have the wrong number of parameters or if argument deduction fails in the case of a function template, or if there is no possible conversion sequence in the case of non-matching argument/parameter types. 3. The best viable function is then chosen - this is where the stuff from 13.3.3 that I quote above, comes in. In the case of two function templates, the first thing that happens is that the specialisations generated from the two templates are compared and if one specialisation is a "better conversion sequence", then that is the preferred function. If neither function is a better conversion sequence, the partial ordering rules (14.5.5.2) are then applied to try and choose. If one of the two function templates is "more specialised" according to the partial ordering rules, then that template is used. =20 However, NOTE - having chosen a function template, only then does the compiler consider explicit specializations of the function template and may select an explicit specialization if it exactly matches the argument types in the call. There is a further twist regarding explicit specialisations - an explicit specialisation can appear to "match" two or more primary function templates i.e. it can be "generated" from more than one function template. The partial ordering rules are used to decide which function template matches the explicit specialisation. Finally, one other little detail to note is that when argument deduction is done, not all parameters necessarily participate in argument deduction and for parameters which don't participate in the deduction (i.e. in the function being called, no deduction occurs for that parameter), then implicit conversion sequences are allowed - but for parameters which participate in deduction, only very limited implicit conversions are allowed (see 14.8.2.1 para 3). You can find some more detail on how overload resolution works with template functions here http://www.gotw.ca/publications/mill17.htm 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 ]