You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
unique_span deletion - destruction and de-allocation - is more complex than one might think. With trivially-constructible types, we can supposed just use new T[size] to start off and then delete[] eventually. But in fact, the code which needs to run when we perform raw allocation and placement-new construction - a-la std::vector - is more complex, and definitely depends on array size. It is problematic to presume we know how to delete given only a pointer and no size, and unable to make a last-minute call about this. Specifically, the current setup makes it impossible to determine how many placement-destruct's are necessary given a pointer.
Moreover, the bespoke deleter causes unique_span's to be nearly non-interchangeable, because their types are deleter-dependent.
Even though it may cost us a few more bytes, let's:
Remove the extra template parameter from `unique_span<T, Deleter> (this means the memory::XXXX:unique_span's will now be just unique_span's)
Use a 'universal' deleter type - which can't just be instantiated
Offer a default, simple, actual deleter
Offer span uspan makers/generators of fixed value and by function.
The text was updated successfully, but these errors were encountered:
* Dropped the deleter template parameter
* Added a deleter member - always of the same type
* The deleter now takes the span
* Added a unique_span generator for non-default-constructible elements
* Dropped the per-memory-space unique_span types - they're all the same type now
* Made the default constructor explicitly zero thing out to avoid spurious deletions of uninitialized / partially uninitialized spans
* Dropped the deleter template parameter
* Added a deleter member - always of the same type
* The deleter now takes the span
* Added a unique_span generator for non-default-constructible elements
* Dropped the per-memory-space unique_span types - they're all the same type now
* Made the default constructor explicitly zero thing out to avoid spurious deletions of uninitialized / partially uninitialized spans
unique_span deletion - destruction and de-allocation - is more complex than one might think. With trivially-constructible types, we can supposed just use
new T[size]
to start off and thendelete[]
eventually. But in fact, the code which needs to run when we perform raw allocation and placement-new construction - a-la std::vector - is more complex, and definitely depends on array size. It is problematic to presume we know how to delete given only a pointer and no size, and unable to make a last-minute call about this. Specifically, the current setup makes it impossible to determine how many placement-destruct's are necessary given a pointer.Moreover, the bespoke deleter causes unique_span's to be nearly non-interchangeable, because their types are deleter-dependent.
Even though it may cost us a few more bytes, let's:
The text was updated successfully, but these errors were encountered: