(Known) Compiler Bug in Vc12

(Known) compiler bug in VC12?

An active issue was posted back in November. The sample code posted was:

Compile and run following code in VS2013

#include <string>

void f(std::string s = {}) {
}

int main(int argc, char* argv[]) {
    f();
    return 0;
}

The bug has been acknowledged by Microsoft.

There doesn't seem to be a work-around posted there. Edit Workarounds can easily be based on avoiding the list-initializer syntax:

void f(std::string s = "");
void f(std::string s = std::string());
void f(std::string s = std::string {});

Or just the old-fashioned (if you don't mind introducing overloads):

void f(std::string s);
void f() { f(std::string()); }

Possible compiler bug in MSVC12 (VS2013) with designated initializer

It is a known bug. It is said to be fixed in the next version of MSVC.

EDIT: Unfortunately, the bug is still present in VS14 CTP 4.

EDIT: This bug has been fixed in VS2015 CTP 5.

Work around for template specialization bug in VC++12?

A sad workaround and i suggest you submit a bug report to connect :

template < int (*)() >
class foo {};

template<int N>
int ReturnsN( ) { return N; }

template<int N>
class bar {
    static int myReturnsN() { return ReturnsN<N>; }
    using fooN = foo< myReturnsN >;
};

Work around compiler bug

My guess is that the compiler is using the defaulted parameter S eps = cg::epsilon<S>() in the deduction of S. For this, it needs to look at the declaration of cg::epsilon<S>() but at this time it doesn't know S yet.

A workaround is avoiding the default value for the third parameter and add two different overloads: the first takes three arguments (a, b and eps) and the second takes only two (a and b). The latter gets eps from cg::epsilon<S>() (at this time S has already been deduced) and delegates the call to the former as the below code shows:

template<class S>
bool eq(S a, S b, S eps)
{
    return true;
}

template<class S>
bool eq(S a, S b)
{
    S eps = cg::epsilon<S>();
    return eq(a, b, eps);
}

Microsoft C++ compiler have a bug?

The expression y * x * 0.25 associates as (y * x) * 0.25 in both C and C++.

When multiplying an unsigned int and a signed int, both operands are converted to unsigned int and the results is also an unsigned int due to the integer conversion rules for arithmetic expressions in both C and C++ so the result of y * x will be UINT_MAX - 1 in both C and C++.

Your example doesn't exhibit a compiler bug whether you are compiling your example as C or C++.

---

Related Topics