А был ли мальчик? (помянем плюсы)

[Pantigalt]

auto_ptr не работает.

Без move семантики невозможно было написать правильный auto_ptr для работы с коллекциями.
Не работает потому что в коллекциях используется по умолчанию конструктор копирования вместо конструктора перемещения которого на тот момент не было.

В С++ 11 с появлением move семантики
1. По умолчанию используется конструктор перемещения
2. Eсли он не определен пользователем или нельзя применить конструктор перемещения по умолчанию то конструктор копирования или конструктор копирования по умолчанию.

[Pantigalt]

Ну, shared_ptr в collections точно работает, а вот предлагаемая замена...

Одной из причин разработки unique_ptr как раз и было предоставление не-shared "умного указателя", совместимого (в отличие от auto_ptr) со стандартными контейнерами. Функциональность shared_ptr избыточна (и, поэтому, его реализация более громоздка и менее эффективна) в ситуациях, когда никакого sharing-а фактически нет.

+1
В простейшем случае когда для unique_ptr нет функции поведения при удалении то используется delete. В этом случае размер в памяти для хранения unique_ptr равно размеру для зранения обычного указателя.
Для shared_ptr используется создается память на куче для хранения счетчика и указателя на функцию удаления.

[AndreyT]

В С++ 11 с появлением move семантики
1. По умолчанию используется конструктор перемещения
2. Eсли он не определен пользователем или нельзя применить конструктор перемещения по умолчанию то конструктор копирования или конструктор копирования по умолчанию.

Вообще-то "симуляция" move semantics в `std::auto_ptr` через `std::auto_ptr::auto_ptr_ref` была достаточной for all means and purposes (хоть местами и опасной). Проблема была в том, что move semantics не принималась во внимание в разработке остальных частей стандартной библиотеки. То есть реализации контейнеров, алгоритмов и т.п. имели право рассчитывать на эквивалентность копирования и требовать этой эквивалентности. Начиная с С++11 move semantics начали принимать во внимание и контейнеры с алгоритмами стали реализовывать более аккуратно.

То есть проблема была не столько в `std::auto_ptr`, сколько в том, что его суррогатную реализацию move semantics не принимали всерьез.

[Pantigalt]

Что все же принципиально нового есть в C++ 11, 14, ... что нельзя было сделать раньше и что значительно расширяет возможности?

Ну с такой точки зрения ничего не "расширяет возможности". Все что есть в С++ можно и всегда будет можно написать и на С, то есть тут как ни старайся, "возможностей" не "расширишь".

Тем не менее, поддержка rvalue references и move semantics - это огромное "расширение возможностей". А также есть auto, возможности делегировать конструкторы... нет смысла копипастить то, что так уже сто раз копипастено.

ksi
Раньше стандартные контейнеры надо было копировать. Теперь их можно перемещать если оригинальный объект уже не нужен.

[Pantigalt]

В С++ 11 с появлением move семантики
1. По умолчанию используется конструктор перемещения
2. Eсли он не определен пользователем или нельзя применить конструктор перемещения по умолчанию то конструктор копирования или конструктор копирования по умолчанию.

Вообще-то "симуляция" move semantics в `std::auto_ptr` через `std::auto_ptr::auto_ptr_ref` была достаточной for all means and purposes (хоть местами и опасной). Проблема была в том, что move semantics не принималась во внимание в разработке остальных частей стандартной библиотеки. То есть реализации контейнеров, алгоритмов и т.п. имели право рассчитывать на эквивалентность копирования и требовать этой эквивалентности. Начиная с С++11 move semantics начали принимать во внимание и контейнеры с алгоритмами стали реализовывать более аккуратно.

То есть проблема была не столько в `std::auto_ptr`, сколько в том, что его суррогатную реализацию move semantics не принимали всерьез.

Я читал что ее намеренно сделали несовместимой со стандартными контейнерами с прицелом на то что изменят это в будущем.

[Medium-rare]

Для shared_ptr используется создается память на куче для хранения счетчика и указателя на функцию удаления.

Не то, чтобы я призывал то или другое использовать в котейнерах.

Чтобы не плодить сущности в случае с контейнером, начиная с C++ 11 moveable тип ему давать.
И жить долго, и счастливо, не зная про требования сегодняшнего дня.

Посмотреть на вещи с практической стороны, и не заболтать.

[M. Ridcully]

Ну, shared_ptr в collections точно работает, а вот предлагаемая замена...

Одной из причин разработки unique_ptr как раз и было предоставление не-shared "умного указателя", совместимого (в отличие от auto_ptr) со стандартными контейнерами. Функциональность shared_ptr избыточна (и, поэтому, его реализация более громоздка и менее эффективна) в ситуациях, когда никакого sharing-а фактически нет.

+1

Я, кстати, до сих пор не понимаю глубоко (ну необходимости просто нет) что такое эти самые move semantics & rvalue references.

Придумал для себя упрощенную картину мира - "это магия, с помощью которой работает unique_ptr". Меня это собственное объяснения пока устраивает.

[Pantigalt]

Для shared_ptr используется создается память на куче для хранения счетчика и указателя на функцию удаления.

Не то, чтобы я призывал то или другое использовать в котейнерах.

Чтобы не плодить сущности в случае с контейнером, начиная с C++ 11 moveable тип ему давать.
И жить долго, и счастливо, не зная про требования сегодняшнего дня.

Посмотреть на вещи с практической стороны, и не заболтать.

Не уверен что я понял что вы хотите сказать.
Вы предлагаете упростить язык и помечать классы модификатором moveable?

[Medium-rare]

Ни тот, ни другой smart pointer не бьют тип с прописанным move, помещённый в контейнер. Это если давить на то, что хорошо.
Полная операбльность, и без потерь в чём-либо. А тут как везде в Интернете, мы себе представляем не совсем то, что говорится.

Дайте контейнерному типу move semantics. Ну, для примера.

[Pantigalt]

Ни тот, ни другой smart pointer не бьют тип с прописанным move, помещённый в контейнер. Это если давить на то, что хорошо.
Полная операбльность, и без потерь в чём-либо. А тут как везде в Интернете, мы себе представляем не совсем то, что говорится.

Дайте контейнерному типу move semantics. Ну, для примера.

Про moveable тип Вы правы.
Ну я и не настаивал на том что надо обязательно использовать умные указатели в контейнерах вместо самих объектов.
Непонятно о чем мы спорим тогда.

[Medium-rare]

Непонятно о чем мы спорим тогда.

Ну, хорошо, в моём стэке застряло такое:

Ну, shared_ptr в collections точно работает, а вот предлагаемая замена...

Одной из причин разработки unique_ptr как раз и было предоставление не-shared "умного указателя", совместимого (в отличие от auto_ptr) со стандартными контейнерами. Функциональность shared_ptr избыточна (и, поэтому, его реализация более громоздка и менее эффективна) в ситуациях, когда никакого sharing-а фактически нет.

И далее обсуждение двух вумных пойнтеров, оба из которых хуже в обсуждаемом применении начиная с C++ 11.
Практический моск взрываццо.

[AndreyT]

Ни тот, ни другой smart pointer не бьют тип с прописанным move, помещённый в контейнер. Это если давить на то, что хорошо.
Полная операбльность, и без потерь в чём-либо. А тут как везде в Интернете, мы себе представляем не совсем то, что говорится.

Дайте контейнерному типу move semantics. Ну, для примера.

К чему это здесь???

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

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

И далее обсуждение двух вумных пойнтеров, оба из которых хуже в обсуждаемом применении начиная с C++ 11.
Практический моск взрываццо.

Хуже чего? Покажите мне, как ваш "тип с прописанным move" поможет хранить в контейнере полиморфные объекты? Покажите мне, как ваш "тип с прописанным move" поможет хранить в контейнере объекты, которые доступны вам только через хэндлы/opaque указатели, предоставленные вам сторонней библиотекой?

`unique_ptr`, `shared_ptr` и т.п. надо применять там, где независимое динамическое выделение памяти и, соответственно, применение указателей уместно или требуется. Приводить примеры неуместного/неправильного использования этих указателей и вдруг критиковать за это сами указатели - это довольно примитивная демагогия.

[Сабина]

Ой, а дайте хороший линк где почитать про лямбды в С++ ?

Ну тут в первую очередь надо понимать, что лямбды в С++ - это (с небольшой натяжкой) просто syntactic sugar, надстроенный над обычными классами. Т.е. лямбда - это просто более компактный синтаксис для локального объявления некоего "безымянного" класса и локального объекта этого класса (closure object). С этой точки зрения можно сказать, что "лямбды" в С++ существовали всегда (опять же, с небольшой натяжкой). Просто раньше для создания "лямбды" надо было выписывать этот локальный класс вручную, используя обыкновенный синтаксис. А теперь то же самое просто записывается более компактно, через новый компактный shorthand синтаксис лямбда-выражения.

Материалов, описывающих эту естественную взаимосвязь, найти можно много
https://eli.thegreenplace.net/2011/11/1 ... das-in-c11

Понимание этого факта существенно облегчает понимание того, что такое лямбда в С++. Поэтому тут встает вопрос: а понимаете ли вы уже все, что нужно, для "ручной" реализации такого класса средствами "классического" С++? Если да, то бОльшая часть понимания того, что такое лямбда, у вас уже есть.

Спасибо, постараюсь разобраться на конкретном примерн как реализовано.
Мне стало интересно потому что скажем в Скале они сразу были (high order functions), а в Джаву потом добавили и мне наверное было бы трудно охватить (хотя Джава - первый язык), не понимай я функционального предназначения лямбд, а именно возможность сериализировать certain kind of generic behavior и переслать копии на несколько remote system для distributed обработки.

[Medium-rare]

Хуже чего? Покажите мне, как ваш "тип с прописанным move" поможет хранить в контейнере полиморфные объекты?

Хороший аргумент. Естественно, что-то вроде d_ptr, но вы правы в данном конкретном случае.

`unique_ptr`, `shared_ptr` и т.п. надо применять там, где независимое динамическое выделение памяти и, соответственно, применение указателей уместно или требуется. Приводить примеры неуместного/неправильного использования этих указателей и вдруг критиковать за это сами указатели - это довольно примитивная демагогия.

Я сам часто использую оба wrapper'а над указателями. Но не для контейнеров. А для контейнеров у меня чаще даже третий вариант. Но не буду разводить водой тред, тем более, третий вариан Qt-специфичный. Ещё, я там пропустил ваш предыдущий пост, поскольку недодумал ответ.

[Prosche]

Я, кстати, до сих пор не понимаю глубоко (ну необходимости просто нет) что такое эти самые move semantics & rvalue references.

Придумал для себя упрощенную картину мира - "это магия, с помощью которой работает unique_ptr". Меня это собственное объяснения пока устраивает.

Нет, это не магия, думайте о move просто как о декларации. Вы сообщаете компилятору, "вызови у класса мув конструктор, который перенесет нутро старого объекта в новый". Все. И те кто будет смотреть на этот код, тоже сразу поймут, что он делает, какой объект валиден, какой нет. никакой двусмысленности. Никакой магии.

[M. Ridcully]

Я, кстати, до сих пор не понимаю глубоко (ну необходимости просто нет) что такое эти самые move semantics & rvalue references.

Придумал для себя упрощенную картину мира - "это магия, с помощью которой работает unique_ptr". Меня это собственное объяснения пока устраивает.

Нет, это не магия, думайте о move просто как о декларации. Вы сообщаете компилятору, "вызови у класса мув конструктор, который перенесет нутро старого объекта в новый". Все. И те кто будет смотреть на этот код, тоже сразу поймут, что он делает, какой объект валиден, какой нет. никакой двусмысленности. Никакой магии.

А компилятор как-то енфорсит неиспользование объекта, из которого сделали move?

Или по-другому спрошу. Может кто-нить написать C-equivalent всего этого безобразия?

[tau]

А компилятор как-то енфорсит неиспользование объекта, из которого сделали move?
Или по-другому спрошу. Может кто-нить написать C-equivalent всего этого безобразия?

А разве это компилятору надо? По идее, создатель объекта и должен позаботиться о том, чтобы объект после операции move оставался в well defined state. Скажем, перенёс из A в Б file handle без клонирования, так A после этого ничего не содержит.
Разве не в этом смысл самой операции move?

[Prosche]

Я, кстати, до сих пор не понимаю глубоко (ну необходимости просто нет) что такое эти самые move semantics & rvalue references.

Придумал для себя упрощенную картину мира - "это магия, с помощью которой работает unique_ptr". Меня это собственное объяснения пока устраивает.

Нет, это не магия, думайте о move просто как о декларации. Вы сообщаете компилятору, "вызови у класса мув конструктор, который перенесет нутро старого объекта в новый". Все. И те кто будет смотреть на этот код, тоже сразу поймут, что он делает, какой объект валиден, какой нет. никакой двусмысленности. Никакой магии.

А компилятор как-то енфорсит неиспользование объекта, из которого сделали move?

Или по-другому спрошу. Может кто-нить написать C-equivalent всего этого безобразия?

компилятор никак не может этого делать. он же не знает в каком состоянии объект.
a(std::move(b));
b.isEmpty(); // true - вполне может быть валидный вызов
или
b.assign("new value");
а вот b.increment(); вполне может и упасть, так как нечего инкрементить, в общем это уже ваше дело не использовать объект если он не валиден.

[AndreyT]

А компилятор как-то енфорсит неиспользование объекта, из которого сделали move?

С чего бы это вдруг он будет его энфорсить? В общем случае использование объекта, из которого сделали move, никак не запрещается. А уж какое использование такого объекта является валидным, а какое не является - вопрос "джентельменских соглашений", компилятору неизвестных. В любом случае, типичным минимумом является поддержка деструкции и присваивания в такой объект.

А если подумать головой, то для объектов, владеющих ресурсами, из соображений эффективности разумнее по возможности реализовывать move через swap - так чтобы moved-from объект в случае присваивания в него мог воспользоваться уже имеющимися ресурсами, вместо того, чтобы выделять с нуля новые.

Или по-другому спрошу. Может кто-нить написать C-equivalent всего этого безобразия?

С-эквивалент мы использовали с испокон веков. Все когда-либо рано или поздно сталкиваются с пониманием того, что в ряде случаев можно/лучше делать move вместо тяжелого copy и реализовывали функции и для того, и для другого. Разница только в том, что в С эти функции надо явно вызвать руками.

[Prosche]

А если подумать головой, то для объектов, владеющих ресурсами, из соображений эффективности разумнее по возможности реализовывать move через swap - так чтобы moved-from объект в случае присваивания в него мог воспользоваться уже имеющимися ресурсами, вместо того, чтобы выделять с нуля новые.

Что за бред?
Вам стоит воспользоваться вашим же советом про голову. Во-первых, с какой стати кто-то передавая объект по && будет ожидать, что в нем появятся какие-то ресурсы. Свап применяют когда известно что объект будет разрушен и делают это по причине атомарности ака безопасности процедуры свапа, перед копированием.
Во-вторых, раз уж вы заговорили о быстродействии, то опять же подумайте, что быстрее, дефолт конструктор + свап или ассайнмент поинтера ресурсов и обнуление поинтера отдающего.

[ksi]

А можно unrelated вопрос? У меня была такая ситуация (я не программист в чистом виде, поэтому сорри, если чего не понимаю): мне нужно создать в памяти копии какого объекта. В большом количестве, сотни тысяч или миллионы потенциально. Поинтеры на новые объекты куда-то положить, ну в массив например. Есть какой-нибудь трюк чтобы это сделать наиболее быстро или ничего кроме цикла из memcpy нельзя придумать? И второй вопрос - а можно это как-то multithreaded или memory manager все равно не способен параллельно выделять память? Или нужен специальный memory manager, которые могут это поддержать? Такие есть?

[ksi]

А можно unrelated вопрос? У меня была такая ситуация (я не программист в чистом виде, поэтому сорри, если чего не понимаю): мне нужно создать в памяти копии какого объекта. В большом количестве, сотни тысяч или миллионы потенциально. Поинтеры на новые объекты куда-то положить, ну в массив например. Есть какой-нибудь трюк чтобы это сделать наиболее быстро или ничего кроме цикла из memcpy нельзя придумать?

Перед тем как советовать implementation желательно понять в чем состоит задача.
Что за объекты? Почему нужны миллионы копий?

Ну произвольная структура какая-то, инстанс какого-то класса. Нважно С или С++. Такая задача, неважно откуда она возникает, это специфическое применения. Потом эти копии будут модифицироваться, слега, ну какое-то поле будет подправлено. Мой опыт, что модификация занимает в сотни раз меньше времени, чем отведение памяти под объект, поэтому и вопрос. Надо сэкономить на копировании.

И второй вопрос - а можно это как-то multithreaded или memory manager все равно не способен параллельно выделять память? Или нужен специальный memory manager, которые могут это поддержать? Такие есть?

Обычно в С++ new and delete реализованы как thread safe.

Это понятно, что они thread safe. Поставить мьютекс ума много не нужно. Но любой multithreaded код, который внутри себя динамически отводит память, пойдет в конечном итоге через memory manager и это может стать bottleneck если таких отведений много. Моя задача - крайний случай, тут вообще ничего нет, кроме отведения памяти.МОжно что-то сделать для ускорения или если смотреть на самый низ, на уровень операционной системы или даже еще ниже, то там принципиально невозможно параллельное выделение памяти?

[alex_127]

Надо пробовать - я близко участвовал в этом деле 10 лет назад и дело в том что части системы везде давно разбиты на правильные кусочки (например списки страниц), вещи типа tlb storm давно починили, но как блокируется адресное пространство одного процесса сильно зависело от оc.

[Pantigalt]

с какой стати кто-то передавая объект по && будет ожидать, что в нем появятся какие-то ресурсы.

Вся эта чехорда с && ссылками и move конструкторами имеет смысл только для объектов которые

а) Не будут использоваться в дальнейшем в текущем контексте.
b) Будут использоваться в другом контексте (другой функции, внешнем контексте).
с) Стоимость копирования в новый объект заметно выше стоимости перемещения в новый объект.

Из этого подразумевается что объект хранит дорогой ресурс иначе смысла в передаче по && особого не было бы.

Свап применяют когда известно что объект будет разрушен

Это не совсем верно например для случая очищения вектора.
Предполагается что вы хотите дальше использовать пустой вектор.

атомарности ака безопасности процедуры свапа

Операция swap не атомарна (с точки зрения многопоточности). Но безопасна потому что не вызывает исключений.