From -7034332304678929117 X-Google-Thread: f78e5,d9fe358a73c69991 X-Google-Attributes: gidf78e5,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!newsgate.cistron.nl!newsfeed.stueberl.de!peer-uk.news.demon.net!kibo.news.demon.net!news.demon.co.uk!demon!stump.algebra.com!devnull From: pmenso57@comcast.net ("Paul Mensonides") Newsgroups: comp.std.c++ Subject: Re: Should failure to instantiate a function template abort compilation during overload resolution? Date: Thu, 11 Aug 2005 14:34:33 GMT Lines: 90 Sender: mail2news@demon.net Approved: fjh@cs.mu.oz.au (Fergus Henderson , moderator of comp.std.c++) Message-ID: References: <1123485075.096196.242990@g44g2000cwa.googlegroups.com> <1123642375.849913.19940@f14g2000cwb.googlegroups.com> NNTP-Posting-Host: news.news.demon.net X-Trace: news.demon.co.uk 1123770885 19952 158.152.254.254 (11 Aug 2005 14:34:45 GMT) X-Complaints-To: abuse@demon.net NNTP-Posting-Date: Thu, 11 Aug 2005 14:34:45 +0000 (UTC) X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) X-DMCA-Complaints-To: dmca@comcast.net X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Priority: 3 X-RFC2646: Format=Flowed; Response X-Virus-Scanned: amavisd-new at cs.mu.OZ.AU X-MSMail-Priority: Normal X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Received: (from fjh@localhost) by mulga.cs.mu.OZ.AU (8.12.10+Sun/8.12.9/Submit) id j7BEYXWB028982; Fri, 12 Aug 2005 00:34:33 +1000 (EST) X-Path: comp-std-cpp-robomod!not-for-mail X-NNTP-Posting-Date: Thu, 11 Aug 2005 02:58:53 -0500 X-Delivered-To: std-c++@ucar.edu X-TN-Interface: 209.99.127.20 X-Postfilter: 1.3.32 X-Authentication-Warning: serv1.gc.dca.giganews.com: news set sender to poster@giganews.com using -f X-Newsreader: Microsoft Outlook Express 6.00.2900.2527 X-Newsgroups: comp.std.c++ Xref: g2news1.google.com comp.std.c++:1763 "Gene Bushuyev" wrote: > "Howard Hinnant" wrote in message >> Compiler writers are understandably apprehensive of being required to >> back out of an arbitrarily complex function which generates an error. > > Compilers traditionally have problems implementing standard. It's not > an argument. If that were impossible (or at least impracticle) to do > then it would be an argument. It may be a particular compiler > implementation has a design that makes recovery difficult, but this > is conceptually nothing new, - the recovery is the same as the recovery from > an exception, no > back-tracking is necessary. Not backtracking, per se, but transactional semantics on the symbol table and other associated compiler state. This could be done if (e.g.) all access to the symbol table was indirected in such a way that a proxy (actually any number of them) could be put between the symbol table and any modifications to it. I.e. +--------------+ | symbol table | +--------------+ | | interface This would be the initial setup; all access to the symbol table is through "interface". When a tentative change to the symbol table could happen, the compiler would put a proxy in: +--------------+ +-------+ | symbol table | --- | proxy | +--------------+ +-------+ | | interface The proxy is basically another symbol table capable of reading from its parent symbol table, but storing all writes inside itself. Upon failure, the proxy is discarded. Upon success, any writes are committed to the symbol table. Or, more precisely, they are committed to whatever is the parent symbol table _or_ proxy in the chain. I.e. a tentative change could occur inside another tentative change, yielding something like: +--------------+ +-------+ +-------+ | symbol table | --- | proxy | --- | proxy | +--------------+ +-------+ +-------+ | | interface The problem is that it is likely to be extremely non-trivial for a compiler to alter its entire code base to work this way (or some similar way). It isn't a simple change by any means. I do believe that it is a worthwhile change, however. In a case like overload resolution, particularly, would-be candidate functions that aren't even selected can create POI's, which, in turn, can cause ODR violations (which aren't currently caught by compilers in many cases) in another POI that is also created by a would-be candidate function that isn't selected. There is a serious risk of this kind of problem (which might well compile anyway despite ODR violations) whenever overloads or specializations are declared away from the primary template or set of overloads and away from the types that they match. For template specializations, this basically means that it is dangerous to define any specialization that doesn't come either with the primary template or with the type that the specialization matches. E.g. third-party template ABC + third-party type XYZ + user-specialization of ABC on XYZ is a recipe for ODR violations--it is an implicit coupling between that specialization and the entire rest of the program. For overloaded functions, especially in light of ADL (which makes namespaces act as interfaces in addition to organizational tools), there isn't a systematic way to avoid the problem in most cases. This situation is a mess, and it would be at least an improvement if the compiler was required to *not* create any POI's (IOW, instantiations) related to any template overload that isn't selected by overload resolution--whether if type deduction fails or not or whether tentative instantiations succeed or not. Doing so virtually requires some kind of transactional semantics or backtracking. Once you have that, it becomes comparatively easy to extend SFINAE such that any "error" excludes the function from the candidate set. In turn, that provides the ability to do nearly arbitrary concept checking as a library component without a special concept checking language feature. Regards, Paul Mensonides --- [ 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 ]