Monday, June 24, 2024

Careful with that initializer_list part 2

initializer_list

 When using Boost.JSON I stumbled upon the following issue:

boost::json::value jv(1);  // creates a number type
boost::json::value jv{1};  // creates an array type

 The value object is something like this:

struct Value
{
   Value(int);
   Value(double);
   Value(std::initializer_list<int>);
};

 This gives the following invocations:

Value vl1(1);  // invokes Value(int) constructor
Value vl2{1};  // invokes Value(std::initializer_list<int>); constructor

 This is a know issue in C++. A programming language should be unambiguously be interpretable and the C++ had decided that in such case the initializer_list has precedence. Not sure if that's a good solution since the ambiguity may only appear when running under the debugger or at customer site. Personally I would require that double braces are used but the C++ committee has decided otherwise. The uniform initialization problem is still not solved.

 

Watch out for atan change in Visual Studio 2022 17.14.6

atan  Recently we updated Visual Studio 2022 17.14.6 and the regression test reported errors. It turned out that atan implementation was cha...