Intel® C++ Compiler
Support and discussions for creating C++ code that runs on platforms based on Intel® processors.
Announcements
This community is designed for sharing of public information. Please do not share Intel or third-party confidential information here.
7680 Discussions

icpc 14.0.1 c++11 SFINAE not working with deleted functions?

Daniel_V_2
Beginner
182 Views

I'm having yet another problem compiling the attached code (which simply attempts to instantiate an unordered_map from int to unique_ptrs.

I've attempted compiling with "icpc --std=c++11 (using g++ 4.8.1's libstdc++)", but the compiler incorrectly stops with an error message when it should only not find that template (in the std-library type_traits) as "substitution failure is not an error".

Both clang 3.3 and g++ 4.8.1 compile this example just fine.

0 Kudos
1 Reply
Judith_W_Intel
Employee
182 Views

 

This looks like the same problem previously reported in the forum here:

http://software.intel.com/en-us/forums/topic/473177

If so this was fixed on 10/13/2013 and should be fixed in the soon to be released 14.0 update (I think it's going to be called 14.0 update 2).

This was a description of the fix:

Deleted special member functions and C++11 SFINAE rules

The front end previously did not always fail template deduction on a reference
to a deleted special member function, as would be required by the C++11 SFINAE
rules.  For example:

  struct S {
    S();
    S(S const&) = delete;
  } s;
  template<class T> int f(decltype(T(s)) *p);  // (1)
  template<class T> char f(decltype(T()) *p);  // (2)
  int main() {
    f<S>(new S);  // Should pick (2).  Previously reported as ambiguous.
  }

In this example, selecting candidate (1) for the call in main() would require
the use of the deleted copy constructor of S.  So the C++11 SFINAE rules
remove that candidate from the set, and that is now correctly done: Candidate
(2) is then selected for the call.  Previously, both candidates competed in
overload resolution, and that resulted in an ambiguity (since the parameter
types are otherwise identical).

Sorry for the inconvenience. I did try your example with our latest development compiler using the GNU 4.8 headers and it compiles fine.

 

Judy

 

 

Reply