Что не так с работой unordered_map?

Question

[kruta]

Есть unordered_map (char*, int, HashFunc, MyEqualTo, CustomAllocator>.
Я не понимаю, как он работает: при инициализации создается CustomAllocator, затем зачем-то вызывается конструктор копирования аллокатора. Буфферы копируются функцией memcpy

В итоге в каком-то аллокаторе вызывается деструктор, все данные удаляются(в т.ч. и выделенные под нужды мапы), вылетает exception в файле xmemory.

Вообще запутался. Объясните, что там такое
Дело в аллокаторе, правда не знаю, что нужно дописать

Аллокатор

#pragma once
#include <vector>


template<class T>
class CustomAllocator
{
public:

	using value_type = T;
	using pointer = T*;
	std::vector<void*>* buffers;
	void* currentBuffer;
	int bufferSize;
	size_t bufferPosition;


	CustomAllocator() noexcept
	{
		bufferSize = 1048576;
		buffers = new std::vector<void*>();
		allocateNewBuffer();
	}

	~CustomAllocator()
	{
		for (int i = 0; i < buffers->size(); ++i)
			if (buffers->at(i) != nullptr)
				delete buffers->at(i);
		delete buffers;
	}

	//CustomAllocator(CustomAllocator& other) :
	//	bufferSize(other.bufferSize), buffers(other.buffers),
	//	currentBuffer(other.currentBuffer), bufferPosition(other.bufferPosition)
	//{
	//	other.buffers = nullptr;
	//	other.currentBuffer = nullptr;
	//}

	////template<typename T1>
	////CustomAllocator(CustomAllocator<T1> other) :
	////	bufferSize(other.bufferSize), buffers(other.buffers),
	////	currentBuffer(other.currentBuffer), bufferPosition(other.bufferPosition)
	////{
	////	other.buffers = nullptr;
	////	other.currentBuffer = nullptr;
	////}


	pointer allocate(std::size_t size)
	{
		if (bufferPosition + size * sizeof(T) >= bufferSize)
			allocateNewBuffer();
		T* pointer = ((T*)currentBuffer + bufferPosition);
		bufferPosition += size * sizeof(T);
		return pointer;
	}

	void deallocate(void* p, std::size_t size)
	{
		bufferPosition -= size;
	}
private:

	void allocateNewBuffer()
	{
		currentBuffer = malloc(bufferSize);
		buffers->push_back(currentBuffer);
		bufferPosition = 0;
	}
};

UPD:
проблема была в том, что создавались копии аллокатора, которые потом уничтожались вместе с буффером, на который и выделялся под данные. В итоге шло обращение к памяти, которая была освобождена. Я так до конца и не понял, зачем нужны были копии

Comments

[Станислав Макаров]

Какую проблему вы решаете кастомным аллокатором?

[kruta]

Станислав Макаров, задачка такая. Свой аллокатор использовать. Он просто выделяет место в массиве

[res2001]

В вашем аллокаторе есть конструктор перемещения и/или операция присваивания перемещением?
Возможно в реализации stl, которой вы пользуетесь, создается временный аллокатор, который затем присваивается постоянному или что-то типа того. Если будет доступен конструктор перемещения, то вероятно будет использоваться он для этого.

Но даже и без перемещения у вас не должно быть исключений (просто объект будет медленней создаваться), похоже ошибка в реализации аллокатора.

[Антон Жилин]

Вообще, лучше в вопросе весь релевантный код выложить. Естественно, под спойлером и в теге code.

[Евгений Шатунов]

kruta, у тебя рядовая проблема понимания аллокаторов. Но о решении говорить еще очень рано.
Тебе нужно предоставить код аллокатора и код инстанцирования std::unordered_map с этим аллокатором.

[kruta]

res2001, дело определенно в моем аллокаторе, правда я не знаю, как исправить

[res2001]

kruta, При копировании у вас копируются только указатели на буферы из вектора buffers, сами буферы при этом остаются одни и те же в двух аллокаторах. Когда один из аллокаторов удаляется он удаляет все буферы, второму аллокатору они уже не доступны, но он об этом ничего не знает.
Вам нужно переопределить конструктор копирования (или запретить) и конструктор перемещения. default вариант вам не подходит.

[kruta]

Да я писал нормальный конструктор копирования, к конструктору перемещения никто не обращается.

template<typename T1>
	CustomAllocator(const CustomAllocator<T1>&) throw()
	{
		buffers = new std::vector<void*>();
		bufferSize = other.bufferSize;
		for (int i = 0; i < other.buffers->size(); ++i)
		{
			auto buf = malloc(bufferSize);
			std::memcpy(buf, other.buffers->at(i), bufferSize);
			buffers->push_back(buf);
		}
		currentBuffer = buffers->back();
		bufferPosition = other.bufferPosition;
	}

Я даже писал конструктор копирования, который не копирует, а инициализирует новые данные.
Постоянно ошибка доступа к памяти в файле xmemory

void _Adopt(const _Container_base12* _Parent) noexcept {
        if (_Parent) {
            // have a parent, do adoption
            _Container_proxy* _Parent_proxy = _Parent->_Myproxy; // Либо здесь эксепшн

#if _ITERATOR_DEBUG_LEVEL == 2
            if (_Myproxy != _Parent_proxy) { // change parentage
                _Lockit _Lock(_LOCK_DEBUG);
                _Orphan_me();
                _Mynextiter                 = _Parent_proxy->_Myfirstiter; // Либо здесь
                _Parent_proxy->_Myfirstiter = this;
                _Myproxy                    = _Parent_proxy;

Answer 1

[Евгений Шатунов]

Дело в том, что контейнер, или умный указатель, в современном C++ может (и делает это) несколько раз сменить аллоцируемый тип шаблонного аллокатора. При этом, оригинальный аллокатор, переданный через конструктор контейнера, будет использован для конструирования нового аллокатора с новым типом. Это означает, что новый аллокатор конструируется не через конструктор копирования, а через конструктор преобразования.

Если в шаблоне алокатора не описано правило смены аллоцируемого типа (A::template rebind<U>::other), по умолчанию при смене аллоцируемого типа будет заменен первый шаблонный параметр. Был у нас Alloc<Foo, ...>, станет Alloc<Bar, ...>.
Это означает что для правильной передачи состояния аллокатора нужно предусмотреть конструктор преобразования из аллокатора от твоего шаблона, но с другим первым аргументом.

Еще можно использовать Polymorphic Allocator, но для этого потребуется сменить стандарт на C++17.
Эту стратегию не так просто описать, поэтому я прибегну к ссылкам на доклады по этой теме.

CppCon 2017: Bob Steagall “How to Write a Custom A...
051. Modern C++ Allocators – Руслан Арутюнян (Intel)
Taming dynamic memory - An introduction to custom ...
C++Now 2018: David Sankel “C++17's std::pmr Comes ...
Это, конечно, далеко не всё на данную тему. Но цели выписывать все у меня и нет. Я привел ссылки, которым доверяю в плане чистоты информации.
Советую просто пройтись по хабру и ytube поиском докладов и статей.

Если сказать очень коротко, то полиморфный аллокатор позволяет создавать аллокаторы с состоянием и более удобным интерфейсом, но работа с такими аллокаторами будет сопряжена с некоторой стоимостью обращения к аллокатору. Стоимостью обращения к стандартному аллокатору, в этом плане, обычно можно пренебречь.

Но если ты работаешь со стандартом до C++11, то у тебя аллокатор вообще не может иметь состояние.

All custom allocators also must be stateless. (until C++11)