Корректная очистка контейнеров в c++11

А зачем пару на куче создавать? Запихни по значению и всё.

Пар будет десяток-другой. Код будет работать для UT, поэтому на производительность тут можно болт положить по идее, да и пары в таком ключе объявлять удобнее.

При чем тут производительность? Это же просто извращение, если в этом нет необходимости.

Не догоняю, предложение состоит в:

	pair<unique_ptr<A>, unique_ptr<B>> newPair1(new A(), new B());
	list<unique_ptr<pair<unique_ptr<A>, unique_ptr<B>>>> pairsList {
		newPair1,
		...
	};

Полагаю, в initializer_list просто так pair<unique_ptr<A>,unique_ptr<B>> не засунешь. Поскольку компилятор тут будет пытаться использовать конструкторы копирования pair(const pair&), а его нет, т.к. нет конструктора копирования для unique_ptr.

предложение состоит в list< pair<A, B> >

Разве он не по месту будет создавать элементы?

GCC 5.2.0 ругается при попытке инициализации list<pair<unique_ptr<A>,unique_ptr<B>>> через initializer_list. Если же заполнять список через emplace_back, то все нормально.

Другое дело, что ТС, вероятно, вообще не нужны unique_ptr и можно обойтись pair<A,B> или tuple<A,B>.

Да, век живи - век учись. Интересно, почему в реализации конструктора с initializer list используется push_back(), а не emplace_back()?

Интересно, почему в реализации initializer list используется push_back(), а не emplace_back()?

Я не настолько копенгаген в деталях реализации работы с initializer list в компиляторе и деталях реализации конструкторов std::list, чтобы ответить на этот вопрос :(

с shared_ptr - да

Да, всё догнал. Поправил на

list<shared_ptr<pair<A, B>>> testPairsList;
testPairsList.emplace_back(new A(), new B());

Но вопрос остаётся в силе: как удалить при этом все объекты пар, хранящиеся в shared_ptr-ах в листе?

Зачем вам вообще создавать A и B в динамической памяти через new?

PS. lovesan не слушайте, он в C++ разбирается как свинья в апельсинах.

Как их создать на стеке?

Нашел вот на SO два ответа: http://stackoverflow.com/a/7231400/2935339

В общем, это зачем-то специально так сделали, а в какой-то старой версии GCC это даже работало.

Могу ошибаться, но ИМХО там new вообще не нужно.

А если так? (не проверял)

list<pair<A, B>> testPairsList;
testPairsList.emplace_back(std::make_pair(A(),B());

Много как. Можно так:

std::list<std::pair<A, B>> pairsList {
	std::make_pair(std::move(A()), std::move(B()))
    };

shared_ptr не нужно пихать куда не попадя.

Точно. Но - как это очищать без итерирования руками?

Давайте поступим проще.

Объекты A и B вам может потребоваться создавать динамически в нескольких случаях:

• эти объекты слишком большие (мегабайты, десятки мегабайт) и их копирование слишком накладно;
• эти объекты не допускают копирования в принципе (например, хранят в себе хендлы внешних ресурсов, как std::ifstream);
• на самом деле A и B — это базовые классы/интерфейсы, а создаются наследники этих классов (через фабрики, к примеру).

Если имеет место один из данных случаев, то в контейнере вам нужно хранить A и B через какой-то умный указатель. В C++11 таких два:

• unique_ptr, который означает эксклюзивное владение объектом. Объект будет разрушен как только будет разрушен unique_ptr. Это очень эффективный умный указатель, но он не может использоваться, если вам нужно иметь живые ссылки на A и B в разных местах программы, а не только в самом list-е;
• shared_ptr, который означает совместное владение объектом. Он не так эффективен как unique_ptr (есть атомарные инкременты/декременты), но зато можно иметь ссылки на A и B в разных местах;

Получается, что если вам нужны именно динамически созданные объекты A и B, и время их жизни определяется временем жизни list-а, в который они помещены, то достаточно иметь list<pair<unique_ptr<A>,unique_ptr<B>>>.

Если нужны динамически созданные объекты A и B, но время их жизни может превышать время жизни list-а, в который они помещены, то нужен list<pair<shared_ptr<A>,shared_ptr<B>>>.

Если же вам вообще не нужно создавать A и B динамически (а во многих случаях как раз не нужно), то достаточно иметь list<pair<A,B>>. При этом память для хранения A и B будет создаваться и освобождаться самим list-ом автоматически, без вашего участия. И вам вообще не нужно думать о том, где A и B размещены.

Вот как-то так, если совсем схематически, хотя могут быть некоторые нюансы.

Зачем это очищать? Оно само очистится при выходе из области видимости. Причем, во всех перечисленных случаях.

Каким образом? Деструктор листа вызывает delete для всех входящих в него элементов? Это фича С++11, или что?

Объекты A и B вам может потребоваться создавать динамически в нескольких случаях:

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

http://www.cplusplus.com/reference/list/list/~list/

std::list::~list
This calls allocator_traits::destroy on each of the contained elements

Это оно?

Вам не нужно очищать содержимое списка руками. Список сам все это делает в нужных местах (деструктор, операции erase, операции копирования и т.д.).

Каким образом? Деструктор листа вызывает delete для всех входящих в него элементов?

delete он не вызовет, но поскольку элементы живут в листе, то для каждого будет вызван деструктор при разрушении листа. На то он и контейнер. Если элемент автоматический указатель, то он вызовет delete (или что ты ему укажешь - хоть лямбду).

Это фича С++11, или что?

Нет, это фича C++ с самого начала.

list<pair<A,B>> pairs {
    { x, y },
    ...
};

тред не читал

(new pair(new A(), new B()))

Это эталон отстрела ног из учебника. Порядок вызова new не гарантирован, exception может сработать во втором из них - теряя ссылку на первый навсегда.

new A()

Можно просто new A. Но нужно просто A().

make_pair(std::move(A()), ...

Зачем делать move для xvalue?

Не «делать», а обозначить :)

Нет, это фича C++ с самого начала.

Где про это можно почитать подробнее? Сколько пользуюсь, а объекты в коллекциях до сих пор не держал.

Здесь например

Ты делаешь какую то хрень

list<pair<A, B>> pairsList {
    make_pair(A(), B(),
    //...
}

И вообще: И эти люди говорят потом что плюсы неудобные и кривые, когда просто использовали их через одно место

Неплохо, спасибо, очень информативно

А если на самом деле? Здесь я никаких подробностей не нашёл.

И вообще

Походу, эти люди просто плюсы никогда не изучали толком.

Ну там как-то кратко, наверное, потому, что это очевидно, но и там вот есть:

A class with the main purpose of holding objects is commonly called a container.

Like all standard-library containers, v ector is a container of elements of some type T; that is, a v ector<T>. Just about any type qualifies as an element type: built-in numeric types (such as char, int, and doub le), user-defined types (such as str ing, Entr y, list<int>, and Matr ix<double,2>) and pointers (such as const char∗, Shape∗, and doub le∗). When you insert a new element, its value is copied into the container. For example, when you put an integer with the value 7 into a container, the resulting element really has the value 7. The element is not a reference or a pointer to some object containing 7. This makes for nice compact containers with fast access. For people who care about memory sizes and run-time performance this is critical.

Ну да, если пытаться использовать плюсы как жабку и сишарп - они жутко неудобные.

Можно и еще короче:

list<pair<A, B>> pairsList{
    { A(), B() },
    //...
};

Это круто, конечно, что ты знаешь, что move это просто каст. Но на вопрос ты не ответил.

Для наглядности. Так и знал, что придет какой-нить «умник» и на это покажет. Хотел посмотреть кто это будет.

Сверхманёвры детектед.

Умник тут пока только тот, кто рассказывал всем известные вещи что «std::move() doesn't move».

Сверхманёвры детектед.

Вот представь себе специально посмотрел сигнатуру std::make_pair в C++11 и написал.

Но вопрос остаётся в силе: как удалить при этом все объекты пар, хранящиеся в shared_ptr-ах в листе? как сделать элегантно без ручного итерирования?

Пул используй с placement new и не насилуй моск «корректными очистками» и прочим преодолением собственноручно созданных трудностей.

Хочу организовать вектор

list<unique_ptr

вектор на основе list? ты на верном пути :)))

Что написал?

То, что написал.

Так зачем ты кастовал rvalue к rvalue?

Чтобы ты спросил.