Pool<T>::newItem leaves trivially copy-constructible types uninitialized

[jeremy]

I have a trivially copy-constructible struct:

	struct MeshInstanceData
	{
		QuatPosScale mTransform = QuatPosScale::identity();
		Float4       mColor     = Float4(1.0f);
	};

and if I create a Pool and do:

auto data = MeshInstanceData();
mMeshInstances.newItem<u32>(data);

the item in the pool is uninitialized (since the placement new isn't called).

plywood/repos/plywood/src/runtime/ply-runtime/container/Pool.h

Lines 378 to 390 in bb78ab5

 template <typename T> 
 template <typename Index, typename... Args> 
 PoolIndex<T, Index> Pool<T>::newItem(Args&&... args) { 
 #if PLY_WITH_POOL_DEBUG_CHECKS 
     // There must not be any Iterators or Ptrs when modifying the pool! 
     PLY_ASSERT(m_numReaders == 0); 
 #endif 
     u32 index = baseAlloc(sizeof(T)); 
     if (!std::is_trivially_constructible<T, Args...>::value) { 
         new (static_cast<T*>(m_items) + index) T{std::forward<Args>(args)...}; 
     } 
     return index; 
 } 

Is the trivially constructible check there to avoid zero initialization? Maybe we could check if args are void? (that's a bit outside my template comfort zone 😀).

(Happy new year! 😬)

[Jeff Preshing]

Hi Jeremy,

Happy new year to you too. I don't think there was a good reason for the std::is_trivially_constructible<> check or for any other possible check at this point for this matter. It was probably a mistake, so I removed it. Fix has been submit. Thanks for reporting this.

Jeff

[jeremy]

You might want to remove the one in delItem item too then :)
Cheers!

[Jeff Preshing]

Yea, I guess that one isn't accomplishing much, is it? I do like to use those type traits around a loop though. I imagine it makes things easier for the compiler in certain build configs. (I'm pretty sure I've seen the compiler fail to optimize away an empty loop in the past.)

cf83a61