Improve memory algorithms with type traits

[Morwenn]

Couldn't the memory algorithms take advantage of type traits to avoid performing unneeded operations? For example, it should be possible to use tag dispatch on std::is_trivially_destructible in destruct to turn it into a no-op when T is indeed trivially destructible. Also uninitialized_move could take advantage of std::is_nothrow_move_constructible to get rid of the exception handling when it's unneeded and could even fall back to std::memmove when std::is_trivially_move_constructible is true.

I guess that compilers can already perform some of these transformations, but I know that at least libc++ tends to use tag dispatch in such cases anyway. On the other hand, I could understand that this repository provides proof-of-concept algorithms and not state-of-the-art ones, but if anyone wants to just use them a is, it might be a valuable addition.

[briterator]

Yes, all of those potential optimizations are part of the motivation for standardizing these. These are now part of C++17 so unless you can't upgrade it's probably best to use your library vendor's version!

[mattreecebentley]

Morwenn,
this is essentially what I do with colony in some areas, and can confirm compilers do not always optimize this stuff automatically (GCC does not).

[Morwenn]

@briterator Well, I don't need those algorithms right now and would certainly use my standard library implementation when available. However, at the time of writing, these algorithms weren't available in standard libraries, so I assumed that some people might be coming here for an out-of-the-box working implementation :)

Anyway, feel free to close the issue if you think that it's not in the scope of this project.

@mattreecebentley That's interesting to hear. I assumed that compilers were able to detect such cases and perform optimizations. I should check the assembly instead of assuming too much ^^'

[mattreecebentley]

I basically benchmarked for/against to find differences. It's conceivable that in some cases the compiler will automagically optimize these scenarios, and not in others.
In terms of the implementations, they're not assumed to be fully-optimized, more test-cases - although in my case I've gone out of my way to optimize the living daylights out of them - but that's my choice :)