"POD" is the wrong type trait to determine if something can be safely
zero-filled in order to achieve zero initialization. Consider a type
like
struct POD { int POD::*ptr; };
This is a POD; its value initialization needs to value initialize the
member, and since it's a pointer, that's zero initialization, and that's
setting the pointer to null.
On Itanium, a null pointer to data member is not zero filled; it actually
has the value -1u.
Hence, zero-filling via memset(0) a POD object like the one above is
erroneous. Unfortunately there is no type trait in C++ that we can use to
know if a given datatype can be value initialized by zero-filling -- we
can check for trivial constructability, but that's a necessary
condition, not a sufficient one (POD above is also trivially
constructible).
The test is disabled on MSVC because of a compiler bug.
Fixes#238
Most template type parameters 'Allocator' were modified their default type to void since 1.70.0.
These modifications cause has_trivial_destructor_after_move to compile error or yield wrong result.
So, fix them by changing specializations of has_trivial_destructor_after_move.
If merge() is called on an empty vector, then priv_merge_in_new_buffer() will
call deallocate() with size 0 on the old (not-yet-allocated) vector storage.
This violates the Allocator requirement that the pointer passed to deallocate()
must have come from a call to allocate() with the same size.
Fix this by checking old_cap against 0, and also add a unit test for this bug.
- Added Extended Allocator support for Boost.Container.
- Improved Doxygen generated reference
- Fixed ticket #9338 ("VS2005 compiler errors in swap() definition after including container/memory_util.hpp")
* Changed again experimental multiallocation interface for better performance (still experimental).
* Added no exception support for those willing to disable exceptions in their compilers.
* Fixed GCC -Wshadow warnings.
* Replaced deprecated BOOST_NO_XXXX with newer BOOST_NO_CXX11_XXX macros.
[SVN r81519]
