А указатель ты как проверишь?

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

Вот именно. И это правильно.

Нужно следить.

В противном случае ты не следишь и у тебя объект никогда может не умереть и непонятно когда он умирает.

зачем тогда вообще юник поинтер, сделай локальный объект на стеке, наплоди объектов со ссылками и работай с ними в скоупе одном. не всегда же все просто

Онтопчик http://manu343726.github.io/2017/03/13/lock-free-job-stealing-task-system-with-modern-c.html

зачем тогда вообще юник поинтер, сделай локальный объект на стеке, наплоди объектов со ссылками и работай с ними в скоупе одном. не всегда же все просто

Это просто синтаксически неудобно.

Но никакой проблемы в классе иметь контейнер или просто филд с юник_птром нет.

Все объекты которые там сложены имеют владельцем инстанс твоего класса.

Всё четко.

Все объекты которые там сложены имеют владельцем инстанс твоего класса.

и по дефолту ты лишаешь себя копирования

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

есть просто крутые приемчики типа таких https://youtu.be/vxv74Mjt9_0?t=33m15s

Нужны boxed!

Интересно, а можно ли эмулировать в плюсах время жизни как в расте?

и по дефолту ты лишаешь себя копирования

Не всегда, на самом деле можно переделать код так, чтобы оставить объекты копируемыми.

кто пользуется conan.io? удобно?

Пользовался немного. Poco им ставил

Интересно, а можно ли эмулировать в плюсах время жизни как в расте?

Вот именно как раз unique_ptr

плюс мув

плюс референсы

Эмулируют поведение как в расте

В точности.

есть просто крутые приемчики типа таких https://youtu.be/vxv74Mjt9_0?t=33m15s

О, это же Sean MMMOKAY Parent.

Hello

А чего .o файлы имеют разную контрольную сумму при пересборке?

Они хранят в себе дату или что?

На глазок оличие в пару байт

-frandom-seed=string This option provides a seed that GCC uses in place of random numbers in generating certain symbol names that have to be different in every compiled file. It is also used to place unique stamps in coverage data files and the object files that produce them. You can use the -frandom-seed option to produce reproducibly identical object files.

Вот именно как раз unique_ptr

Гуж.

Они хранят в себе дату или что?

это тебе было

это тебе было

Сеньку

Сеньку

правда там такое еще The string should be different for every file you compile

Ок, еще спрошу про unique_ptr. Вот у меня есть функция, которая создает объект A и возвращает unique_ptr<A>. Дальше, я добавляю его в контейнер std::map<int, unique_ptr<A». Как только я заполнил контейнер мне надо его скопировать в другой такой же контейнер и очистить. Собственно вопрос как скопировать std::map<int, unique_ptr> в такой же? С shared_ptr я просто делаю cont1 = cont2 и далее cont2.clear();

Ок, еще спрошу про unique_ptr. Вот у меня есть функция, которая создает объект A и возвращает unique_ptr<A>. Дальше, я добавляю его в контейнер std::map<int, unique_ptr<A». Как только я заполнил контейнер мне надо его скопировать в другой такой же контейнер и очистить. Собственно вопрос как скопировать std::map<int, unique_ptr> в такой же? С shared_ptr я просто делаю cont1 = cont2 и далее cont2.clear();

Мувни

Ок, еще спрошу про unique_ptr. Вот у меня есть функция, которая создает объект A и возвращает unique_ptr<A>. Дальше, я добавляю его в контейнер std::map<int, unique_ptr<A». Как только я заполнил контейнер мне надо его скопировать в другой такой же контейнер и очистить. Собственно вопрос как скопировать std::map<int, unique_ptr> в такой же? С shared_ptr я просто делаю cont1 = cont2 и далее cont2.clear();

Да, ты можешь этот контейнер просто смувать в новый.

можно конструкцию)) я понимаю что можно мувнуть)) синтаксически как это сделать?

можно конструкцию)) я понимаю что можно мувнуть)) синтаксически как это сделать?

huynya2=std::move(huynya1)

пошел пробовать, спасибо!

newContainer = std::move(oldContainer);

Или если в конструкторе, то прям newContainer(std::move(oldContainer));

не не. контейнер существует уже

не не. контейнер существует уже

std::map::merge

Еще интересный момент возник. А как мне вернуть из контейнера std::map<int, unique_ptr<A» указатель на объект A по индексу i. в функцию с такой вот сигнатурой take_A(A *a);

map[i].get()

владение объектом само собой передается?

глупость спросил))

get у нас вернет указатель на объект в unique_ptr, а сам unique_ptr останется или как? не очень этот момент понятен

Да, с самим объектом ничего не будет.

Просто вернёт указатель.

аа он const вернет

аа он const вернет

вроде нет

pointer get() const;

Это из cppreference

это значит, что метод сам по себе не меняет содержимое объекта

поля объекта unique_ptr

да да

а если в функции кто-нибудь попытается освободить память по указателю, то что станет с unique_ptr? Тут гарантий получается нет?

а если в функции кто-нибудь попытается освободить память по указателю, то что станет с unique_ptr? Тут гарантий получается нет?

сделает delete второй раз. если ты занулил указатель, то ничего страшного

звучит как дикие хаки какие-то

используешь умные указатели — забудь про ручное освобождение памяти

а если в функции кто-нибудь попытается освободить память по указателю, то что станет с unique_ptr? Тут гарантий получается нет?

вот и возвращай им указатель на конст

ибо нехуй

ну тут такое...)) это объекты protobuf. и я их передаю в функцию set_allocated_ Есть подозрение что он удаляет эти объекты после отработки

С протобуфом надо по-совему обращаться да.

Протобуф сам отслеживает время жизни.

Протобуф сам отслеживает время жизни.

вот. поэтому скорее всего освобождаться память будет дважды насколько я понял

Но по-хорошему ты можешь спокойно брать тупо указатели на подполя и подобъекты протобуфовского объекта, покуда сам объект жив.

У себя в проекте я именно так и делаю.

Хотя я стараюсь нигде протобуф объекты не хранить а использовать прямо по месту на стеке.

Хотя я стараюсь нигде протобуф объекты не хранить а использовать прямо по месту на стеке.

они жэ уродские

все поля называются маленькими буквами

через ()

ну привыкаешь))

ну привыкаешь))

я за год не привык

ппц

да лааадно

да лааадно

а у всех меседжей есть бейс клас?

там код генерируется жесткий. ну по крайней мере для меня. а уж имена... хрен с ними

а у всех меседжей есть бейс клас?

скорее всего

там код генерируется жесткий. ну по крайней мере для меня. а уж имена... хрен с ними

с кодом то хрен чай, в него смотреть не надо а вот имена приходится постоянно юзать

Наследуются от google::protobuf::Message все

скорее всего

я не нашол, сделал всю логеку на шаблонах

??

вот. поэтому скорее всего освобождаться память будет дважды насколько я понял

https://developers.google.com/protocol-buffers/docs/reference/cpp-generated#proto3_string Цитата: void set_allocated_foo(string* value): .... the message takes ownership of the allocated string object .... string* release_foo(): Releases the ownership of the field and returns the pointer of the string object.....

Если делаешь set_allocated, который берешь из юника, то потом релиз сделай

И не будет двух удалений

Не потом, а сразу.

И не будет двух удалений

?

Немного не ту ссылку дал, там на строки

https://developers.google.com/protocol-buffers/docs/reference/cpp-generated#embeddedmessage

Про объекты

Наследуются от google::protobuf::Message все

а вот кстати какие ты имена даёш в прото файле ? мемберам

message Battery { required uint32 id = 1; required int32 u = 2; required int32 t = 3; }

вот пример

ппц \

человек будет делать Battery.t()

вот дофига прозрачно

bat.set_id(12);