Return to Answer

##Comment on testing

If you are not going to bother with delete then you may as well write a much simpler version.

##Code Review

You should mark you move operator as noexcept.

    pool(pool&& o)  // Why is this not noexcept here.

The standard way to implement this is using swap(). See my implementation above. This handles situations like this in a safe way.

Should this not be char*. The call offsetof() returns the offset in bytes. The char by definition fits into 1 byte, thus a char* is a 1 byte addressable range. Also the standard has special properties for char* that other integer types don't have.

##Comments on testing code.

You could use placement new to make them more similar. But personally I would override the new/delete operator so that it uses your pool.

You are forcing a move of all the iterators in the vector. Rather than erasing it just free the memory and set the pointer to nullptr. That would be a much better test.

You should use exactly the same code for both tests. The only difference should be the allocator used. You should have one test that uses your custom allocator. While the second test uses an allocator that simply calls new/delete underneath the hood.

Comment on testing

If you are not going to bother with delete then you may as well write a much simpler version.

Code Review

You should mark your move constructor as noexcept.

    pool(pool&& o) noexcept;

The standard way to implement this is using swap(). See my implementation above. This handles situations like this in a safe way.

Should this not be char*? The operator offsetof() returns the offset in bytes. The char by definition fits into 1 byte, thus a char* is a 1 byte addressable range. Also the standard has special properties for char* that other integer types don't have.

Comments on testing code

You could use placement-new to make them more similar. But personally I would override the new and delete operators so that they use your pool.

You are forcing a move of all the iterators in the vector. Rather than erasing it, just free the memory and set the pointer to nullptr. That would be a much better test.

You should use exactly the same code for both tests. The only difference should be the allocator used. You should have one test that uses your custom allocator. While the second test uses an allocator that simply calls new/delete underneath the hood.

##Comment on testing If you are not going to bother with delete then you may as well write a much simpler version.

They should be noexcept anyway good to let the language police that for you (it terminates if it actually throws). Also it can help if you were to use your pool with standard libraries as it enables some optimizations.

Otherwise your are testing the memory manager code. Which is very complex and will give you different results (because memory has all ready been messed with in a previous test).

That is way to small a test.

Both of these allocators will finish in the blink of an eye. You want a test that last a couple of seconds to get real information.

##Comment on testing

If you are not going to bother with delete then you may as well write a much simpler version.

They should be noexcept anyway; good to let the language police that for you (it terminates if it actually throws). Also it can help if you were to use your pool with standard libraries as it enables some optimizations.

Otherwise you are testing the memory manager code. Which is very complex and will give you different results (because memory has already been messed with in a previous test).

That is way too small a test.

Both of these allocators will finish in the blink of an eye. You want a test that lasts a couple of seconds to get real information.

You should mark you move operator as no-throw.

    pool(pool&& o)  // Why is this not nothrow here.

They should be no-throw anyway good to let the language put that extra testing in for you. Also it can help if you were to use your pool with standard libraries as it enables some optimizations.

You should mark you move operator as noexcept.

    pool(pool&& o)  // Why is this not noexcept here.

They should be noexcept anyway good to let the language police that for you (it terminates if it actually throws). Also it can help if you were to use your pool with standard libraries as it enables some optimizations.