Follow-up: C++ 'evolutionary AI' implementation

Based on the advice provided in my previous question, I would like to post the other source file that actually implements all the combat mechanics and also the actual evolution process.

As with the previous question, I am interested in all kinds of feedback — regarding design, implementation, algorithms, presentation, style, cleanliness, correct C++11 usage, or anything that you think that could make this work better as an impressive code sample submitted to support a job application.

The entire code as well as the rules can be seen at http://www.mz1net.com/code-sample — that is also where the 'MechArena.h' that declares the classes and describes them a little better is available.

```
#include
#include

#include "MechArena.h"

// COMPONENT SET ========================================================================
// ======================================================================================

// The no-param constructor initialises the component list with random components.
template
Components::Components (size_t size)
{
for (size_t m = 0; m ::randomComponent();
this->components.push_back(component);
}
}

// ======================================================================================

// The 'crossover' constructor creates a new Components instance that randomly mixes the
// components used by the two provided parents component sets. Some components will also
// be randomly switched to a random component due to mutation.
template
Components::Components (const Components& c1, const Components& c2)
{
size_t c1Size = c1.components.size();
size_t c2Size = c2.components.size();
if (c1Size != c2Size)
{
throw std::exception("Crossover is impossible between component sets that do not have the same size.");
}

// For each component in the set, decide randomly which parent's component the new
// component set will inherit. For optimisation, we request one random number and use
// its bi

Don't like all the switches (I suppose you are doing it for speed (doubt it makes a difference)).

I would a couple of tests to see if using switches actually does make a significant difference, compared to virtual functions in terms of speed in your use case scenarios.

But it (switches) makes the code a mess and hard to compartmentalize (maintain/fix), I would use classes to encapsulate meaning and prevent bugs. It also makes bugs more likely.

Prefer to throw std::runtime_error rather than std::exception. It narrows down the type you need to catch at runtime. PS if you are really going for speed then exceptions can be more costly than virtual function calls (but measure).

I prefer putting const on the right (there is one corner case where it matters). But the community is still split over this so you take it or leave it:

std::ostream& operator& c) 

I prefer:

std::ostream& operator const& c) 
                                                   //     ^^^^^^

// Its a const ref.

It also makes reading types easier. As you read types from right to left and const always binds to the left (unless it is the first item then in binds right).

// Components const&
//                    ^  Reference to
//               ^^^^^   const
// ^^^^^^^^^^^^^         Components

   char const * const   data  = "Plop";
   char const * const&  data1 = data;
//                   ^      Reference to
//              ^^^^^       Const
//            ^             Pointer to
//      ^^^^^               Const
// ^^^^                     char

StackExchange Code Review Q#39141, answer score: 3