Merge sort code review response.

http://codereview.stackexchange.com/questions/88298/modern-c-compliant-merge-sort/88373?noredirect=1#comment159964_88373

Prefer to use move rather than copy semantics.
A+ deifnitely slipped my mind on this, and previous, algorithms.

Too many lines of parameters.
Stylistic decision, but my style agrees; the mergesort routine only has 3 parameters, it doesn't even make it to the global print width of 80 characters.

Memer types names.
This applies to typedefs within functions too? I have noticed that this is necessary for things at global scope, but I guess it would make it easier on me to just always use it rather than worry about when to use it.

Type name.
This is a stylistic conventional decision that I don't think I would abide by.
I don't like mixing pascalcase with lowercase_underscore syntax used by the Standard Library.

Don't pass comparator to merge by value.
I ended up "Merging" the merge function ;) with the sort function to optimize it. I haven't used merge anywhere else, plus I would still have std::merge so it's one decision I wouldn't mind doing.

Non optimal implementation.
Does using a ternary operator here really help that much more with efficiency? Because you're sacrificing some readibility imo.
If you wanted to inline so much you could also omit the curly braces from the while and make `*out = ...` into `*out++ = ...` :) Although i'm not sure about possible the efficiency improvements that would lead from this.
(I'm still not knowledgeable enough to do the whole "analyze the bytecode" thing that some people do.)

Space optimization.
Perform the copies in the merge code. Got it.
Also, I should look into merge sorting linked lists, because I have seen that you wouldn't even require secondary storage for linked lists.

Result.
There is only one type of input iterator because we know we are sorting two halves of the same container.
    So you're saying we don't even need bidirectional iterators in this case, but rather input iterators?

There is no output iterator as the merge is done in place.
    Don't you need output iterators simply because, even though the merge is done in place, you need to swap or move around values? Input iterators to my knowledge are for input only.

The comparitor does not need a default type.
this is done as part of the sort_merge template.
    Ok, good observation, but I merged the functions anyway.

I don't pass two ranges.
I use begin/mid/end
    You have less overhead by 1 iterator copy, but you lose the ability to merge data from separate arrays?

Thanks again for your thoughts!
-Falven