Templates rejected on non-dependent parameters before deduction in C++0X?
in [C++]
|
Prev: stl function adapter to compare struct member
Next: Does the C++ standard define the global function of " istream& operator >>(istream& in, string& str); "?
From: Jesse Perla on 11 Jun 2010 07:41 On Jun 11, 7:34 am, Daniel Kr�gler <daniel.krueg...(a)googlemail.com> wrote: > On 11 Jun., 03:13, Jesse Perla <jessepe...(a)gmail.com> wrote: > Personally I consider the FCD wording as clear and sufficient > at least for C++0x. Extending SFINAE cases beyond that > would put extremely strong requirements on implementations to > be able to handle arbitrary deep instantiation errors within > templates. I guess where I am getting confused is that I don't see this as a SFINAE problem. I am not using an extended version of SFINAE to choose the overload here, but rather the overload is determined from matching the signature as normal templates occur. Why should the compiler instantiate templates for functions that have already been removed from the overload possibilities? But I trust your judgement on this and I am certainly not a compiler writer... if you think that this should fail and the wording is sufficient and changing it would open up a can of worms, then I will leave Microsoft alone. But it seems like people are using meta-functions to determine return types very frequently these days, so I think this problem might pop up frequently. For example, Intel's simpler example that they are targeting looks even more like it should intuitively work to a mediocre programmer like me: template <class T> struct Z { typedef T::x type; }; template <class T> typename Z<T>::type f(void *, T); template <class T> void f(int, T); struct A {} a; int main() { f(1, a); // Okay now. Formerly provoked an error on the instantiation // of the Z<T> in the return type, with T=A. Now the first f // is ruled out on the basis of the first parameter without // doing deduction and producing the routine type. } > A possible workaround is to define > a trait template has_value and to use classical enable_if techniques > to filter the unwanted overload away. So, instead of writing This is similar to the meta-function I wrote, but the actual implementation of the return type is much more complicated, so things got ugly quickly. Thanks for taking a look at this. -Jesse > > template<typename T> > struct my_meta1 > { > typedef typename T::value value; > > }; > > you could write > > template <typename T> > struct has_value { > template <typename> struct wrapper {}; > template <typename U> static char test(wrapper<typename U::value>*); > template <typename> static char (&test(...))[2]; > static const bool value = sizeof(test<T>(0)) == 1; > > }; > > template<typename, bool = has_value<T>::value> > struct my_meta1 {}; > > template<typename T> > struct my_meta1<T, true> > { > typedef typename T::value value; > > }; > > HTH & Greetings from Bremen, > > Daniel Kr�gler > > -- > [ Seehttp://www.gotw.ca/resources/clcm.htmfor info about ] > [ comp.lang.c++.moderated. First time posters: Do this! ] { It is often frustrating for readers to scroll through a long quoting only to find out that the quoted part was not commented on but just left unremoved. It is a proper etiquette to quote only the parts you are commenting on and remove anything else, especially things like the greeting, the signature and the clc++m banner. -mod } -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Daniel Krügler on 11 Jun 2010 15:08 On 12 Jun., 00:41, Jesse Perla <jessepe...(a)gmail.com> wrote: > On Jun 11, 7:34 am, Daniel Kr�gler <daniel.krueg...(a)googlemail.com> > wrote: > > > On 11 Jun., 03:13, Jesse Perla <jessepe...(a)gmail.com> wrote: > > Personally I consider the FCD wording as clear and sufficient > > at least for C++0x. Extending SFINAE cases beyond that > > would put extremely strong requirements on implementations to > > be able to handle arbitrary deep instantiation errors within > > templates. > > I guess where I am getting confused is that I don't see this as a > SFINAE problem. > > I am not using an extended version of SFINAE to choose the overload > here, but rather the overload is determined from matching the > signature as normal templates occur. Sure, but your reference to the standard part that describes what we usually nominate as the base for SFINAE, implied for me that you wanted the SFINAE cases to become extended. > Why should the compiler instantiate templates for functions > that have already been removed from the overload possibilities? The tricky point is, that you seem to assume that an implementation will first check, whether the function would be removed, before doing (declaration) instantiations. > But I trust your judgement on this and I am certainly not a > compiler writer... Neither am I, but I have talked to some of them and they reported to me that this is no easy task (in general). There can be very subtle reasons why an overload would never match. > if you think that this should fail and the wording is > sufficient and changing it would open up a can of worms, > then I will leave Microsoft alone. I was arguing against the "grey area", but I didn't want to keep you from asking your vendor for better QoI. As I said, this is clearly a question of QoI. In contrast, I would like to encourage you to do so, because if at one day basically all implementations do implement this current feature, there will be a clear chance that this feature will be standardized. Note that the C++ standardization is not a theoretical project, it is strongly influenced by what the current technical status quo is, and this again is determined by customer requests. My main points are: a) I don't think that SFINAE cases will be much increased in the future in regard to deep instantiation errors within class templates b) I don't think that we have already the time such that most implementations do implement early rejections like in your example. HTH & Greetings from Bremen, Daniel Kr�gler -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Jesse Perla on 12 Jun 2010 19:01
On Jun 12, 2:08 am, Daniel Kr�gler <daniel.krueg...(a)googlemail.com> wrote: > Sure, but your reference to the standard part that > describes what we usually nominate as the base for > SFINAE, implied for me that you wanted the SFINAE > cases to become extended. Actually, I may miscommunicated. The reference I made was repeating Microsoft's answer when I asked them if they would my example work so I would have portability with GCC and Intel (who said they would fix it). I never thought of this as an SFINAE problem because I wasn't using the return type to manage overloads, which is why I was somewhat confused by their answer. > The tricky point is, that you seem to assume that an > implementation will first check, whether the function > would be removed, before doing (declaration) instantiations. Yeah, I think you are right... that is how I was thinking of it. Sounds like this is left to be implementation specific in the C++0X standard. > I was arguing against the "grey area", but I didn't want > to keep you from asking your vendor for better QoI. As > I said, this is clearly a question of QoI. Microsoft and Intel said that it was grey in the C++03 and clear in C+ +0X. > feature will be standardized. Note that the C++ > standardization is not a theoretical project, it is > strongly influenced by what the current technical > status quo is, and this again is determined by customer > requests. My main points are: > > a) I don't think that SFINAE cases will be much > increased in the future in regard to deep instantiation > errors within class templates > > b) I don't think that we have already the time such that > most implementations do implement early rejections like > in your example. OK. Since Microsoft chose to flag my request as "By Design", unless I can come up with a better argument about why it should be consistent with GCC/Intel, then they aren't going to look at this again. Part of this is understanding if they are interpreting the standard correctly (and more importantly, that the part of the standard they refer to is the appropriate one and not a red herring). If anyone thinks that they should support the examples I posted, then add in a comment justifying it in: https://connect.microsoft.com/VisualStudio/feedback/details/560886/bug-in-template-expansion-during-function-overload-resolution Thanks, Jesse -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |