Open jnk0le opened 1 year ago
Can you elaborate on this? Looking through the code it's not obvious what or where a failure would occur.
Currently insert/removal uses copy constructors everywhere, (i.e. T a = b;
) which als means memory leak if T
is allocating anything.
As I understand, this should work fine if the author of the class has properly implemented the copy assignment operator. For example, if T
is std::shared_ptr
, the copy assign would first decrement the usage count of the pointer held in a
and then increment the usage count of the pointer held in b
.
copy assignment
ah, assignment, not constructor.
It will still leak until given slot is reused for new data, not to mention that the buffer array is uninitialized.
I'll add the assert until figuring out the std::move + rval refs and all of the related "what ifs".
I think the slot would hold onto memory until reuse, but that’s much better than a leak because the buffer size is bounded.
Anyway thanks for the library!
The copy assignment a = b
is ok if the copy assignment operator of type T
is implemented.
It is responsibility of the maintainer of type T
to ensure that current resources is freed before copy resources from others.
Is my understand correct?
Currently the buffer array is uninitialized, so that will be very undefined operation.
This would also make the copy constructors unusable for it's intended purpose.
Currently the buffer array is uninitialized, so that will be very undefined operation.
This would also make the copy constructors unusable for it's intended purpose.
I see. So, if the type can be default constructed, then it will be fine?
As long as all members are also trivially (default) constructible.
should use move mechanic or put another static assert