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. 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.
  
• functional programming style over object oriented. Why not make the regex functions member functions? This will help intellisense which is an important aspect for programming these days. 
• uniform initialization. Again the committee f*cked up. Could be fixed by using double braces (e.g.std::vector<size_t>{{2}})

Besides these aspects the C++ language misses an extended standard library. One need frequent 3th party libraries for basic things. This could have been alleviated if there was a standard package manger with de facto libraries but 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.

 

Careful with std::ranges

<ranges>

  C++20 has added the the ranges library. Basically it works on ranges instead of iterators but added some subtle constraints to some algorithms. For example consider the lower_bound algorithm:

#include <algorithm>
#include <utility>

using IntPair = std::pair<int, int>;
   
IntPair a[1];

auto it = std::lower_bound(std::cbegin(a), std::cend(a), 1, [](const IntPair& r, int n) { return r.first < n; });

The lower_bound function only expects an asymmetric functor implementing the order between container and search element. To spare on typing out the begin and end iterator one could think to use the ranges library:

auto it = std::ranges::lower_bound(a, 1, [](const IntPair& r, int n) { return r.first < n; });

This gives though a ton of mystic error messages on VStudio:

1>error C2672: 'operator __surrogate_func': no matching overloaded function found
1>error C7602: 'std::ranges::_Lower_bound_fn::operator ()': the associated constraints are not satisfied
1>message : see declaration of 'std::ranges::_Lower_bound_fn::operator ()'

It turns out that the ranges variant expect a functor with all less combinations defined:

struct OpLess
{
   bool operator() (const int n1, int n2) const                 { return n1 < n2; };
   bool operator() (const IntPair& r1, const IntPair& r2) const { return r1.first < r2.first; };
   bool operator() (const IntPair& r, int n) const              { return r.first < n; };
   bool operator() (int n, const IntPair& r) const              { return n < r.first; };
};

auto it = std::ranges::lower_bound(a, 1, OpLess{});

Side note: concepts supposed to give more clearer error messages but are cryptic as well.

External links

•  Does ranges::lower_bound have different requirements for the comparison than std::lower_bound?

Careful with std::shared_ptr

std::shared_ptr

std::shared_ptr is a C++ smart pointer who takes shared ownership of the pointee. It solves some of the memory problems associated with the C language which are memory leaks; buffer overruns and dangling pointers. The first two can be solved by using std::vector; the first and last one by using std::shared_ptr. shared_ptr has though some sharp edges:

• one can create cycles between std::shared_ptr (i.e. A points to B; B points to A). The memory isn't released then. Solution is to use std::weak_ptr to break the cycle. Alternatively one can use a raw pointer to point back to the owner.
• never assign a 'raw' resource to two std::shared_ptr's. Instead once a resource is assigned to a std::shared_ptr use the std::shared_ptr to share that resource.
• use enabled_shared_from_this to hand out a std::shared_ptr of yourself. This fails in constructor because the std::shared_ptr structure is build after the constructor returns.

Garbage collectors don't suffer from these issues but the runtime price one pays for it is large. Also their non-deterministic destruction may another big hurdle to coop with.

Scrum is the cancer of ICT

Scrum

  The company I work for decided 5 years ago to switch to a more Agile / Scrum development method. A consultant promised the CEO that with this method we would be more effective and he used some bullshit use case found on internet. 

Since then two major projects have failed due to the following reasons:

• sprints of 3 weeks are too short to achieve substantial development
• focus on short term - easy achievable goals. A pitfall fueled by easy to check off backlog items and tasks
  
• work on core and foundation has not much attention. Hard to show and demonstrate to your stakeholders this kind of work.
• make small pieces and of software and patch / refactor later is not a way to build stable buildings let alone software
• lot of administrative overhead with daily standup's; sprint review; grooming sessions; retrospective etc.
• Agile promised to offer better dealing with shifting requirements but this is a false promise.

Not sure why the world has gone mad but our company was doing a lot better beforehand. A false fallacy is often used to compare this method with the waterfall method with rigid requirements once written down. However no company works that way.

Watch out for MSVC's std::map's move constructor

move constructor

 The other day I found out that MSVC's std::map move constructor doesn't have noexcept:

map(map&& _Right) : _Mybase(_STD move(_Right)) {}

This means that it can throw when moved and it's not eligible for move_if_noexcept which is used in vector reallocation's. I filed a report but it got rejected. Take care when you want map's to be moveable (which can be a factor compared to copying all nodes).

Watch out for vector one argument constructor

vector constructor

 Aggregate initialization brought us many good things. There is though one nasty pitfall with std::vector. std::vector can be initialized with a size_t to specify its initial size. There is a potential ambiguity since the vector also accepts size_t as its element type:

#include <cassert>
#include <vector>

int main()
{
   std::vector<size_t>  vec0(5);   // vector size is set
   std::vector<size_t>  vec1{5};   // vector size isn't set directly but vector is initialized with 1 element

   assert(vec0.size() == 5);
   assert(vec1.size() == 1);

   std::vector<size_t>  vec2{vec0.size()};  // even worse: vectors do not have the same size now

   return 0;
} 

This is especially a problem with 32 bits code where size_t is an int typedef. A solution is that the C++ committee resolves the ambiguity e.g. by introducing a 2 argument overload for vector constructor (with an extra enum). Until then it's watching out 

Reference:

• Code analysis warning when using brace initialization in vector and one argument