C++ horrible aspects

C++ horrible aspects

 Linus Torvalds described C++ as being a horrible language. While C++ has its dark corners I choose it any day over any other language. Especially compared to C with its major security liabilities. There are some questionable aspects though: 

• 'rvalue' references becoming 'lvalue' references. Not sure who invented this but he or she should be banned from the committee. Super confusing that a type can change.
  
• universal references and perfect forwarding. Again a very confusing idea to reuse the 'rvalue' reference syntax. The reference collapsing rules doesn't make it easier either
  
• two phase lookup. Confusing rule which could have been solved by stating that a template definition is only checked at instantiation time. No more need for 'typename' or making types and member functions (non) dependent since at instantiation time all type and context information is known
• lack of uniformity in STL. For example there is reset and clear. Some algorithm's have _if variants when taking functors; others not.
• functional programming style over object oriented. Why not make the regex functions member functions? It prevents clutter of std namespace. It will probably also help Intellisense to build up its database which is important help in IDE's these days. 
• uniform initialization. Again the committee made a mistake. The issue could be fixed by requiring double braces in case constructor invocation (e.g.std::vector<size_t>{{2}})
• the ranges library has some strange aspects as well as can be seen here. 

Besides these aspects C++ misses out on an extended standard library. Especially compared to .NET or Java where many things are present in their extensive standard library. One need frequent 3th party libraries (e.g. Boost) for basic things. This could have been alleviated if there was a standard package manger like in Python with de facto libraries but again there isn't.

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 JSON value object has constructor definitions something like these:

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. The ambiguity can be solved by requiring double braces in case there are overloads like this but the all wise C++ committee has decided otherwise. The uniform initialization problem is still not solved.

 Edit: this behavior has now been patched as of Boost 1.86. If the initializer_list has size 1 it's assumed to be a single value type instead of array. Original behavior can be mimicked by using BOOST_JSON_LEGACY_INIT_LIST_BEHAVIOR. Pretty smart trick t.b.h.