Передача объектов по значению, производительности и unique_ptr

Я работаю с библиотекой C++, которая не была написана мной. В настоящее время я пытаюсь немного улучшить библиотеку, удалив множество круговых зависимостей.Передача объектов по значению, производительности и unique_ptr

Libray общается по сети и имеет некоторые классы сообщений, которые создаются при чтении данных, полученных из сети.

В настоящее время он работает так:

сообщение анализируется и std::unique_ptr<Message> создается.
сообщение передается на родительский объект с std::move(msg)

я удалил циклическую зависимость от сети синтаксического анализа на родительский объект и используется сигнал, вместо того, который испускает std::shared_ptr<Message>. Мне интересно, было бы неплохо просто передать сообщение по значению вместо shared_ptr. Это снизит производительность?

В библиотеке проходит множество объектов с unique_ptr. Это хорошая практика?

Заранее спасибо

EDIT:

Message состоит из трех unsigned int и std::map<string, string>, который не будет держать больше, чем несколько строк

источник

2014-02-19 schlimpf

Если вы получили сообщение через сетевое копирование, вероятно, не будет проблемой. – kazemakase

так передайте объект по значению вместо unique_ptr? Я думаю, это было бы гораздо более читаемым. Или есть недостатки? – schlimpf

Передача по значению обязательно скопирует карту. Если это возможно, это зависит от вашего приложения.Если вы обрабатываете сообщение только раз в то время и не заботитесь о задержках при передаче сообщения, это должно быть осуществимо. Боюсь, что только профилирование может дать вам окончательный ответ. – kazemakase

Насколько велика сообщение, и большие части подвижны?

Если ваше сообщение, скажем, int и две std :: strings, конструктор перемещения должен быть довольно быстрым. Независимо от того, что ухудшает вашу производительность, зависит от того, насколько вы это делаете.

Однако будьте осторожны при копировании сообщения, если оно велико.

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

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

источник

2014-02-19 10:19:56

Я отредактировал вопрос по вашей запрошенной информации. Было бы лучше использовать unique_ptr или просто передавать вещи по стоимости, что, на мой взгляд, приводит к гораздо более читаемому коду. – schlimpf

При использовании одной функции std :: это может быть потокобезопасно, не так ли? Я думал, что boost :: signals2 является потокобезопасным – schlimpf

Регистрация в signal2 является потокобезопасной. С помощью std :: function назначение не является. Но вам это нужно? Действительно ли ваш класс начинает получать сообщения в одном потоке, пока обратный вызов еще не определенно зарегистрирован? –

В общем случае объекты, не связанные с константой, обернутые в shared_pointers, не очень хорошо подходят для асинхронных и многопоточных приложений. Приложение может стать намного более сложным из-за предотвращения потенциальных расследований данных.

Возможно, было бы лучше передать объекты по значению или unique_pointer, если только эти объекты не являются const.

Относительно производительности: вы можете использовать семантику перемещения.

источник

2014-02-19 10:29:04 CouchDeveloper

Что вы подразумеваете при использовании семантики перемещения? Проходя мимо значения? – schlimpf

Я думал, что с использованием shared_pointers/unique_pointers использование объектов является потокобезопасным – schlimpf

@schlimpf Семантика перемещения: см. SO: http://stackoverflow.com/questions/3106110/what-is-move-semantics. Что касается безопасности потоков: shared_pointer сам по себе является потокобезопасным, объект, где он указывает (возможно), требует дополнительной синхронизации. – CouchDeveloper

Передача объектов по значению, производительности и unique_ptr

ответ

Смежные вопросы