Should failure to instantiate a function template abort comp - C++ language, library and standards

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Should failure to instantiate a function template abort comp
Goto page 1, 2 Next

C++Talk.NET Forum Index -> C++ language, library and standards

View previous topic :: View next topic

Author

Message

wuyongwei@gmail.com
Guest

Posted: Mon Aug 08, 2005 8:27 am Post subject: Should failure to instantiate a function template abort comp

The discussion in comp.lang.c++.moderated: http://groups-beta.google.com/group/comp.lang.c++.moderated/browse_thread/thread/3c449572456c8592 Paul Mensonides's post seems decisive. However, this failure is ugly, counter-intuitive, and user-unfriendly (not to mention that the error messages I have seen are all very confusing since they say everything unrelated to the user's code). Anyone knows of anything improved in this aspect? Best regards, Yongwei --- [ 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 ]

Howard Hinnant
Guest

Posted: Wed Aug 10, 2005 1:06 am Post subject: Re: Should failure to instantiate a function template abort

In article <1123485075.096196.242990 (AT) g44g2000cwa (DOT) googlegroups.com>,
[email]wuyongwei (AT) gmail (DOT) com[/email] wrote:

Quote:

The discussion in comp.lang.c++.moderated:

http://groups-beta.google.com/group/comp.lang.c++.moderated/browse_thread/thre
ad/3c449572456c8592

Paul Mensonides's post seems decisive. However, this failure is ugly,
counter-intuitive, and user-unfriendly (not to mention that the error
messages I have seen are all very confusing since they say everything
unrelated to the user's code). Anyone knows of anything improved in
this aspect?

CodeWarrior is experimenting with an enable_if-like return type on
std::distance so that this overload will not participate in overload
resolution if InputIterator isn't an iterator. Your example on our
implementation will compile and set d == 2 at runtime.

-Howard

---
[ 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 ]

Gene Bushuyev
Guest

Posted: Wed Aug 10, 2005 5:45 am Post subject: Re: Should failure to instantiate a function template abort

"Howard Hinnant" <hinnant (AT) metrowerks (DOT) com> wrote

Quote:

In article <1123485075.096196.242990 (AT) g44g2000cwa (DOT) googlegroups.com>,
[email]wuyongwei (AT) gmail (DOT) com[/email] wrote:

The discussion in comp.lang.c++.moderated:

http://groups-beta.google.com/group/comp.lang.c++.moderated/browse_thread/thre
ad/3c449572456c8592

Paul Mensonides's post seems decisive. However, this failure is ugly,
counter-intuitive, and user-unfriendly (not to mention that the error
messages I have seen are all very confusing since they say everything
unrelated to the user's code). Anyone knows of anything improved in
this aspect?

CodeWarrior is experimenting with an enable_if-like return type on
std::distance so that this overload will not participate in overload
resolution if InputIterator isn't an iterator. Your example on our
implementation will compile and set d == 2 at runtime.

But the question is not whether it's possible to circumvent this problem in
std::distance or any other function for that matter. The question is what is
the intention of the standard, because after long discussion it's still not
clear. Should the failure to implicitly instantiate the return type during
argument deduction during overload resolution be a program error or does
14.8.3/1 kick in and function should be simply excluded from the overload
set of candidates (SFINAE), no error reported. If the first is the intention
of the standard then the following test case will or will not compile
depending on whether the definition for "struct traits" is provided, which
is counterintuitive. If the second is the intention of the standard, then
all the best compilers are miserably failing. And here again is the test:

template<class T>
struct traits
#if defined(PROVIDE_DEFINITION)
{
typedef typename T::no_such_type no_such_type;
}
#endif
;

template<class T> typename traits<T>::no_such_type foo(T);

int foo(int);

int test()
{
return foo(0);
}

- gene

---
[ 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 ]

Wu Yongwei
Guest

Posted: Wed Aug 10, 2005 6:45 am Post subject: Re: Should failure to instantiate a function template abort

Howard Hinnant wrote:

Quote:

Thanks for your informatiom. Do you think this is the way to go? I
mean, does anyone in the C++ committee realize that it might be a
defect in the Standard that violates the rationale of the std namespace
and can be very confusing to innocent users that happen to define their
own versions of distance(std::...)?

My current opinion is that failure to instantiate a template function
should automatically remove it from the candidates of overload
resolution.

Comments please.

Best regards,

Yongwei

---
[ 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 ]

Richard Corden
Guest

Posted: Wed Aug 10, 2005 2:44 pm Post subject: Re: Should failure to instantiate a function template abortc

Hi,

Gene Bushuyev wrote:

[...]

Quote:

Although this example looks like SFNAE kicks in, it doesn't. As soon as
instantiation of a class begins SFNAE no longer applies. The error is
actually occurring before overload resolution takes place while the
compiler is trying to specialise the function type to see if it can be
added to the overload set.

template <typename T>
struct A
{
friend class B;
};

template <typename T>
typename T::TYPE foo (T); // Does use SFNAE

template <typename T>
typename A<T>::TYPE foo (T); // Does not use SFNAE

void foo (int);

void bar ()
{
foo (0);
}

// ...

typedef int B;

If the compiler did allow you to instantiate class bodies, it would then
have a lot of difficulty back tracking. In this example, a completely
unrelated typedef would now generate an error since there is already a
'class B' declared in the namespace.

Regards,

Richard

--
Richard Corden

---
[ 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 ]

Gabriel Dos Reis
Guest

Posted: Wed Aug 10, 2005 2:46 pm Post subject: Re: Should failure to instantiate a function template abort

"Wu Yongwei" <wuyongwei (AT) gmail (DOT) com> writes:

Quote:

Howard Hinnant wrote:
CodeWarrior is experimenting with an enable_if-like return type on
std::distance so that this overload will not participate in overload
resolution if InputIterator isn't an iterator. Your example on our
implementation will compile and set d == 2 at runtime.

Thanks for your informatiom. Do you think this is the way to go? I
mean, does anyone in the C++ committee realize that it might be a

The C++ committee realizes that uncontrolled argument dependent name
lookup causes problems in some circumstances. The proper fix seems
unclear however. Many people have different opinions about what the
fix should be. For the latests, google for "a modest proposal" and
"Herb Sutter", and the latest concept papers.

Quote:

defect in the Standard that violates the rationale of the std namespace

The issue has nothing specific to do with namespace std. I would have
considered it a problem was the namespace called foobar and the
function called freebies.

---
[ 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 ]

Howard Hinnant
Guest

Posted: Wed Aug 10, 2005 2:47 pm Post subject: Re: Should failure to instantiate a function template abort

In article <1123642375.849913.19940 (AT) f14g2000cwb (DOT) googlegroups.com>,
"Wu Yongwei" <wuyongwei (AT) gmail (DOT) com> wrote:

Quote:

My current opinion is that failure to instantiate a template function
should automatically remove it from the candidates of overload
resolution.

Compiler writers are understandably apprehensive of being required to
back out of an arbitrarily complex function which generates an error.
By "back out", I mean the compiler would have to put itself in the exact
same state as it had before it began the function instantiation. I'm
not saying it is impossible to do so, just that this would be a new and
non-trivial requirement on the compiler.

As mentioned in the c.l.c++.m thread, concepts (if accepted) may create
this requirement and may resolve your issue.

-Howard

---
[ 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 ]

Gianluca Silvestri
Guest

Posted: Wed Aug 10, 2005 4:20 pm Post subject: Re: Should failure to instantiate a function template abort

"Howard Hinnant" <hinnant (AT) metrowerks (DOT) com> ha scritto nel messaggio
news:hinnant-7A2DC8.09274510082005 (AT) syrcnyrdrs-03-ge0 (DOT) nyroc.rr.com...

Quote:

In article <1123642375.849913.19940 (AT) f14g2000cwb (DOT) googlegroups.com>,
"Wu Yongwei" <wuyongwei (AT) gmail (DOT) com> wrote:

My current opinion is that failure to instantiate a template function
should automatically remove it from the candidates of overload
resolution.

Compiler writers are understandably apprehensive of being required to
back out of an arbitrarily complex function which generates an error.
By "back out", I mean the compiler would have to put itself in the exact
same state as it had before it began the function instantiation. I'm
not saying it is impossible to do so, just that this would be a new and
non-trivial requirement on the compiler.

What about keeping in the overload set those function templates that now
cause a compile error , mark them in some way and proceed with overload
resolution. If one of them win the match then the compiler issue an error,
otherwise the best one is chosen.

---
Gianluca Silvestri

---
[ 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 ]

chris jefferson
Guest

Posted: Wed Aug 10, 2005 5:30 pm Post subject: Re: Should failure to instantiate a function template abort

Gianluca Silvestri wrote:

Quote:

"Howard Hinnant" <hinnant (AT) metrowerks (DOT) com> ha scritto nel messaggio
news:hinnant-7A2DC8.09274510082005 (AT) syrcnyrdrs-03-ge0 (DOT) nyroc.rr.com...
| In article <1123642375.849913.19940 (AT) f14g2000cwb (DOT) googlegroups.com>,
| "Wu Yongwei" <wuyongwei (AT) gmail (DOT) com> wrote:
|
| > My current opinion is that failure to instantiate a template function
| > should automatically remove it from the candidates of overload
| > resolution.
|
| Compiler writers are understandably apprehensive of being required to
| back out of an arbitrarily complex function which generates an error.
| By "back out", I mean the compiler would have to put itself in the exact
| same state as it had before it began the function instantiation. I'm
| not saying it is impossible to do so, just that this would be a new and
| non-trivial requirement on the compiler.
|

What about keeping in the overload set those function templates that now
cause a compile error , mark them in some way and proceed with overload
resolution. If one of them win the match then the compiler issue an error,
otherwise the best one is chosen.

Not being insulting, but what you suggest is of course a simple overview
of how any implementation of this would have to work. I am but an
amateur in the field of writing C++ compilers (I'm trying to slowly
understand g++), but I can see that what is being asked for is very
complex. If Howard Hinnant tells you something is hard, you are highly
unlikely to come up with a cunning means of solving it in a paragraph
and 30 seconds thought :)

Also, I imagine some people (including myself) might be causious about
exactly what "failure to instantiate" would cover. For example, consider
that I meant to write iterator_traits<T>::value_type in a
specialisation, but I accidentally wrote iterator_traits<T>::valuetype
instead. It might be very hard to spot this problem, as the compiler
would simply try to instansiate the function, fail, and carry on and do
the less optimized version (yes of course, there are already ways you
can slip up in similar ways, but they are limited (I believe) purely to
the definition of functions / classes).

Chris

---
[ 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 ]

chris jefferson
Guest

Posted: Thu Aug 11, 2005 5:24 am Post subject: Re: Should failure to instantiate a function template abort

Howard Hinnant wrote:

Quote:

I had thought about using a similar technique on many other of the
functions in std::, for example to stop functions matching if they are
given incorrect iterator types, which should hopefully lead to better
(or at least much smaller) error messages. However I was under the
impression that all functions had to have exactly the same signiture as
they do in the standard? Am I wrong?

Chris

---
[ 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 ]

Howard Hinnant
Guest

Posted: Thu Aug 11, 2005 5:26 am Post subject: Re: Should failure to instantiate a function template abort

Quote:

Paul Mensonides's post seems decisive.

The question is what is the intention of the standard,

I agree with Paul's analysis.

-Howard

---
[ 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 ]

Gene Bushuyev
Guest

Posted: Thu Aug 11, 2005 5:31 am Post subject: Re: Should failure to instantiate a function template abort

"Howard Hinnant" <hinnant (AT) metrowerks (DOT) com> wrote

Quote:

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. So maybe it's time to start writing compilers in
C++ to make it easier.

But that aside, at this point we are trying to understand what the standard
actually requires. And it looks to me that the standard prescribes the
following set of actions:

// --- almost c++ code for compiler ---

Function overload_resolution(function_name, arguments)
{
set<Function> overload_set;
set<Function> failed_set;
for(Function function = parse_tree.functions.begin();
function != parse_tree.functions.end(); ++function)
if(function->name == function_name
&& function->check_lookup_rules())
{
if(function->is_a_template()
{
try
{
if(! function->is_explicitly_specialized())
template_arguments =
function->deduce_template_arguments(arguments); //
14.8.2
instance = function->instantiate(template_arguments) //
14.7.1
overload_set.insert(instance); // 14.8.3/1
}
catch(...)
{
failed_set.insert(*function); // only for reporting purposes
// do nothing with this candidate according to 14.8.3/1
}
}
else
overload_set.insert(*function);
}

set<Function> matched_set = overload_set.find_best_viable_function();

if(matched_set.empty())
throw no_match_error(failed_set); // just a hint for user - not
required

if(matched_set.size() > 1)
throw many_match_error(matched_set);

// don't instantiate templates unless necessary 14.7.1/9
if(matched_function.is_a_template_instance())
compiler.instantiated_function_set.insert(matched_function);

return matched_function;
}

I'm sure I missed details, but I hope I got the general picture right.

- gene

---
[ 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 ]

Wu Yongwei
Guest

Posted: Thu Aug 11, 2005 6:32 am Post subject: Re: Should failure to instantiate a function template abort

Gabriel Dos Reis wrote:

Quote:

"Wu Yongwei" <wuyongwei (AT) gmail (DOT) com> writes:
| Thanks for your informatiom. Do you think this is the way to go? I
| mean, does anyone in the C++ committee realize that it might be a

The C++ committee realizes that uncontrolled argument dependent name
lookup causes problems in some circumstances. The proper fix seems
unclear however. Many people have different opinions about what the
fix should be. For the latests, google for "a modest proposal" and
"Herb Sutter", and the latest concept papers.

Thanks for this useful info.

Quote:

| defect in the Standard that violates the rationale of the std namespace

The issue has nothing specific to do with namespace std. I would have
considered it a problem was the namespace called foobar and the
function called freebies.

Yes, you are right. But logically my statement was not wrong either.
:-)

Best regards,

Yongwei

---
[ 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 ]

Pavel Kuznetsov
Guest

Posted: Thu Aug 11, 2005 2:33 pm Post subject: Re: Should failure to instantiate a function template abort

Richard,

Quote:

template <typename T
struct A
{
friend class B;
};

template typename T::TYPE foo (T); // Does use SFNAE

template typename A
void foo (int);

void bar ()
{
foo (0);
}

// ...

typedef int B;

I fail to see why you're saying that SFINAE does not take place in
the second case, and in fact the standard contains a similar example:

14.8.2/2 <...> Type deduction may fail for the following reasons:
<...>
- Attempting to use a type in the qualifier portion of a qualified
name that names a type when that type does not contain the
specified member, or if the specified member is not a type where
a type is required. [Example:
template <class T> int f(typename T::B*);
struct A {};
struct C { int B; };
int i = f<A>(0);
int j = f<C>(0);
]

14.8.3/1 <...> If, for a given function template, argument deduction
fails, no such function is added to the set of candidate functions
for that template.

Quote:

If the compiler did allow you to instantiate class bodies, it would then
have a lot of difficulty back tracking. In this example, a completely
unrelated typedef would now generate an error since there is already a
'class B' declared in the namespace.

This is exactly what Comeau Online and VC++8 beta 2 has to say for your
example:

====

"ComeauTest.c", line 23: error: invalid redeclaration of type name "B"
(declared at
line 4)
typedef int B;
^

1 error detected in the compilation of "ComeauTest.c".

===

..test.cpp(36) : error C2371: 'B' : redefinition; different basic types
.test.cpp(17) : see declaration of 'B'

--
Pavel

---
[ 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 ]

Paul Mensonides
Guest

Posted: Thu Aug 11, 2005 2:34 pm Post subject: Re: Should failure to instantiate a function template abort

"Gene Bushuyev" wrote:

Quote:

"Howard Hinnant" <hinnant (AT) metrowerks (DOT) com> 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.

+--------------+

Quote:

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:

+--------------+ +-------+

Quote:

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:

+--------------+ +-------+ +-------+

Quote:

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 ]

Display posts from previous:

	C++Talk.NET Forum Index -> C++ language, library and standards	All times are GMT Goto page 1, 2 Next
Page 1 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum