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 which has major liabilities. There are some questionable aspects though: 

• 'rvalue' references becoming 'lvalue' references. Not sure who invented this but he 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
• 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}})

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 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.