This subject came up in this thread about a change to std::list::sort() for Visual Studio 2015:
`std::list<>::sort()` - why the sudden switch to top-down strategy?
The new version of std::list::sort does not require a default constructible std::list, as it only uses iterators, and doesn't create any local lists, so it doesn't matter if lists can't be default constructed. The prior version uses local lists (note - each instance of a list involves a dynamic allocation of a sentinel node):
typedef list<_Ty, _Alloc> _Myt;
// ...
const size_t _MAXBINS = 25;
_Myt _Templist, _Binlist[_MAXBINS];
I'm trying to create a non-default constructible list, with Visual Studio 2015 version to test how the change to std::list::sort() handles this.
First I tried the Microsoft C++ 11 minimal allocator example. udpate - I had to change one line in order for Jonathan Wakely's answer to work and demonstrate the issue:
template <class T>
struct Mallocator
{
typedef T value_type;
// Mallocator() noexcept {} // replaced this line from the Microsoft example
Mallocator(T) noexcept {} // no default constructor
// A converting copy constructor:
template<class U> Mallocator(const Mallocator<U>&) noexcept {}
template<class U> bool operator==(const Mallocator<U>&) const noexcept
{
return true;
}
template<class U> bool operator!=(const Mallocator<U>&) const noexcept
{
return false;
}
T* allocate(const size_t n) const;
void deallocate(T* const p, size_t) const noexcept;
};
template <class T>
T* Mallocator<T>::allocate(const size_t n) const
{
if (n == 0)
{
return nullptr;
}
if (n > static_cast<size_t>(-1) / sizeof(T))
{
throw std::bad_array_new_length();
}
void* const pv = malloc(n * sizeof(T));
if (!pv) { throw std::bad_alloc(); }
return static_cast<T*>(pv);
}
template<class T>
void Mallocator<T>::deallocate(T * const p, size_t) const noexcept
{
free(p);
}
update - with Mallocator changed to have no default constructor, this now results in a compile error:
typedef unsigned long long uint64_t;
std::list <uint64_t, Mallocator<uint64_t>> dll; // doubly linked list
Using the suggested change from Jonathan Wakely works and reproduces the issue where the old std::list::sort gets a compile error due to local lists and shows that the new std::list::sort with no local lists works with no default constructor:
std::list<uint64_t, Mallocator<uint64_t>> dll(Mallocator<uint64_t>(0));
I also tried this method based on a thread here at SO:
struct Allocator {
void construct(void* p, const void* container) const {};
void destruct(void* p, const void* container) const {};
};
void* operator new (size_t size, const Allocator& alloc, const void* container)
{
void* allocated_memory = std::malloc(size);
if (!allocated_memory) {
throw std::bad_alloc();
}
alloc.construct(allocated_memory, container);
return allocated_memory;
}
void operator delete(void* p, const Allocator& alloc, const void* container)
{
alloc.destruct(p, container);
std::free(p);
}
In main
typedef unsigned long long uint64_t;
// ...
Allocator alloc;
std::list<uint64_t> *dll = new(alloc, NULL)std::list<uint64_t>;
// ...
operator delete(dll, alloc, NULL);
but this works for both the old and new versions of std::list::sort, so it's getting a default constructor.
So the question was how do I create a non default constructible allocator?
Thanks to the demo from Igor Tandetni and answer from Jonathan Wakely, I was able to change the Microsoft example allocator above (noted in the comments) to not have a default constructor, and reproduce the issue related to the old std::list::sort.
If you default construct a std::list
then it will default-construct its allocator, so this variable definition still requires a default constructor:
std::list <uint64_t, Mallocator<uint64_t>> dll; // doubly linked list
If you want to test allocators without default constructors you need to do it differently e.g.
std::list <uint64_t, Mallocator<uint64_t>> dll(Mallocator<uint64_t>(args));
Or:
Mallocator<uint64_t> alloc(some, args, for, your, allocator);
std::list <uint64_t, Mallocator<uint64_t>> dll(alloc);
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With