Занимаясь последние несколько дней оптимизацией старого кода столкнулся несколько раз с ситуациями, для которых в C++0x придуманы rvalue references. Но в C++98 их нет, поэтому пришлось написать собственный велосипедик. Его код приведен ниже.
Если кому-то приходилось делать что-нибудь подобное самому или же кто-то видит в данном решении явные ляпы, то поделитесь, пожалуйста информацией и впечатлениями. Буду очень признателен.
//
// temporary_object_ref_t
//
/*!
* \since v.2.4.0
* \brief Шаблон ссылки на временный объект.
*
* Данный класс является вспомогательным инструментом для
* компенсации отсутствия в C++98 т.н. rvalue references из
* будущего стандарта C++0x.
*
* <b>Пример использования.</b> Допустим есть некоторый
* контейнер тяжеловесных объектов (например, std::vector<int>).
* Иногда добавляемое в контейнер значение нужно скопировать и
* создать новую копию в контейнере, для чего предназначен
* метод add, получающий константную ссылку на std::vector<int>:
* \code
* class heavy_object_container_t
* {
* public:
* void add( const std::vector<int> & obj ) {
* m_underlying_storage.push_back( obj );
* }
* ...
* private:
* std::list< std::vector<int> > m_underlying_storage;
* };
* \endcode
* Но иногда заранее известно, что при добавлении объекта в
* контейнер используется временный объект, который будет
* выброшен сразу после добавления. В этом случае операцию
* добавления можно реализовать более эффективно -- забрать из
* аргумента метода add имеющееся в нем значение:
* \code
* void add( std::vector<int> & obj ) {
* m_underlying_storage.push_back( std::vector() );
* m_underlying_storage.back().swap( obj );
* }
* \endcode
* При таком подходе желательно, чтобы сигнатура метода add для
* временного объекта явно указывала, что она требует именно
* временный объект.
*
* В C++0x для этих целей применялись бы rvalue references, a
* для C++98 предназначен данный класс:
* \code
* void add( temporary_object_ref_t< std::vector<int> > obj ) {
* m_underlying_storage.push_back( std::vector() );
* m_underlying_storage.back().swap( obj.writeable() );
* }
* \endcode
*/template< class T >
class temporary_object_ref_t
{
public :
/*!
* Инициализирующий конструктор.
*
* Пользователь должен гарантировать, что время жизни
* объекта \a o будет большей, чем время жизни данного
* экземпляра temporary_object_ref_t.
*/explicit temporary_object_ref_t( T & o )
: m_object( o )
{}
/*!
* Получение ссылки временный объект для последующего
* изменения временного объекта.
*/
T &
writeable()
{
return m_object;
}
/*!
* Получение константной ссылки на временный объект.
*/const T &
readonly() const
{
return m_object;
}
private :
//! Ссылка на временный объект.
T & m_object;
};
/*!
* \since v.2.4.0
* \brief Вспомогательная функция для упрощения формирования
* ссылки на временный объект.
*
* Пример использования:
* \code
* void make_and_add_next_item(
* heavy_object_container_t & container )
* {
* std::vector< int > next_item;
* ...
* container.add( make_temporary_object_ref( next_item ) );
* }
* \endcode
*/template< class T >
temporary_object_ref_t< T >
make_temporary_object_ref( T & o )
{
return temporary_object_ref_t< T >( o );
}
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Если кому-то приходилось делать что-нибудь подобное самому или же кто-то видит в данном решении явные ляпы, то поделитесь, пожалуйста информацией и впечатлениями. Буду очень признателен.
template< class T >
temporary_object_ref_t< T > make_temporary_object_ref( T & o )
{
return temporary_object_ref_t< T >( o );
}
Помойму здесь ошибка и это недолжно компилироваться точно также как и это
Здравствуйте, eao197, Вы писали:
E>Доброго дня!
E>Занимаясь последние несколько дней оптимизацией старого кода столкнулся несколько раз с ситуациями, для которых в C++0x придуманы rvalue references. Но в C++98 их нет, поэтому пришлось написать собственный велосипедик. Его код приведен ниже.
E>Если кому-то приходилось делать что-нибудь подобное самому или же кто-то видит в данном решении явные ляпы, то поделитесь, пожалуйста информацией и впечатлениями. Буду очень признателен.
Здравствуйте, eao197, Вы писали:
E>Доброго дня!
E>Занимаясь последние несколько дней оптимизацией старого кода столкнулся несколько раз с ситуациями, для которых в C++0x придуманы rvalue references. Но в C++98 их нет, поэтому пришлось написать собственный велосипедик. Его код приведен ниже.
E>Если кому-то приходилось делать что-нибудь подобное самому или же кто-то видит в данном решении явные ляпы, то поделитесь, пожалуйста информацией и впечатлениями. Буду очень признателен.
Во внутренностях boost'a есть несколько реализаций эмуляции move semantics.
boost/interprocess/detail/move.hpp
boost/ptr_container/detail/move.hpp
boost/variant/detail/move.hpp //This file derivative of MoJO.
...
Есть еще библиотечка Boost.Move.Пока она не является частью boost'a, но вроде обещают доделать и включить.
В девичестве это Adobe Move Library). Там же есть свои реализации контейнеров, адаптированные к перемещениям.
Здравствуйте, eao197, Вы писали:
E>Доброго дня!
E>Занимаясь последние несколько дней оптимизацией старого кода столкнулся несколько раз с ситуациями, для которых в C++0x придуманы rvalue references. Но в C++98 их нет, поэтому пришлось написать собственный велосипедик. Его код приведен ниже.
E>Если кому-то приходилось делать что-нибудь подобное самому или же кто-то видит в данном решении явные ляпы, то поделитесь, пожалуйста информацией и впечатлениями. Буду очень признателен.
В том числе, есть и move ссылки. move::t<T &>. Никаких placement new и явных вызовов деструкторов (в отличии от Adobe версии).
Использовать можно не только как rvalue reference, но и просто для перемешения. Например, перемещение тяжелых элементов вектора при изменении его размера. Как пример, реализация вектора, только на new и delete без reinterpret_cast и placement new. Можно использовать несколько вложенных векторов (вектор векторов векторов ...) без потери производительности при изменении размеров (resize).
По хорошему, все контейнеры и типы должны поддерживать такой move. В cbear это справедливо для оболочек над COM типами: SAFEARRAY, BSTR, указатели на интерфейсы, структуры и т.д., все поддерживают конструкторы T::T(move::t<T> const &) и присваивания T &operator=(move::t<T> &).
. Последняя версия здесь.
_>В том числе, есть и move ссылки. move::t<T &>. Никаких placement new и явных вызовов деструкторов (в отличии от Adobe версии).
_>Использовать можно не только как rvalue reference, но и просто для перемешения. Например, перемещение тяжелых элементов вектора при изменении его размера. Как пример, реализация вектора, только на new и delete без reinterpret_cast и placement new. Можно использовать несколько вложенных векторов (вектор векторов векторов ...) без потери производительности при изменении размеров (resize).
Все это конечно интересно, но моих мозгов не хватает для понимания всех деталей работы версий move от Adobe, Boost-а и вашего решения в cbear.
Я свое примитивное решение сделал только для того, чтобы явно помечать в коде места, в которых производится оптимизация посредством изымания значения из временного объекта. Для моих конкретных нужд этого хватило.
А вот фреймворки для поддержки move-семантики, имхо, тупиковый путь. Здесь должно быть стандартное решение в самом языке, а не в виде библиотек.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
. Последняя версия здесь.
_>>В том числе, есть и move ссылки. move::t<T &>. Никаких placement new и явных вызовов деструкторов (в отличии от Adobe версии).
_>>Использовать можно не только как rvalue reference, но и просто для перемешения. Например, перемещение тяжелых элементов вектора при изменении его размера. Как пример, реализация вектора, только на new и delete без reinterpret_cast и placement new. Можно использовать несколько вложенных векторов (вектор векторов векторов ...) без потери производительности при изменении размеров (resize).
E>Все это конечно интересно, но моих мозгов не хватает для понимания всех деталей работы версий move от Adobe, Boost-а и вашего решения в cbear.
E>Я свое примитивное решение сделал только для того, чтобы явно помечать в коде места, в которых производится оптимизация посредством изымания значения из временного объекта. Для моих конкретных нужд этого хватило.
На самом деле, cbear_berlios_de::move::t<T> и есть тот самый врап, который помечает в коде те самые места Все остальное, это описание возможностей
E>А вот фреймворки для поддержки move-семантики, имхо, тупиковый путь. Здесь должно быть стандартное решение в самом языке, а не в виде библиотек.
Возможно. Но, пока в самом языке этого нет, алтернативных решений кроме библиотек я не вижу.
Здравствуйте, sergey_shandar, Вы писали:
E>>Я свое примитивное решение сделал только для того, чтобы явно помечать в коде места, в которых производится оптимизация посредством изымания значения из временного объекта. Для моих конкретных нужд этого хватило.
_>На самом деле, cbear_berlios_de::move::t<T> и есть тот самый врап, который помечает в коде те самые места Все остальное, это описание возможностей
Ну не совсем так. Как я понял, ваша реализация расчитана на перемещение объектов, у которых есть метод move_assign. Если же нужно реализовать move-семантику для объектов, у которых такого метода нет, то все -- ваше решение не применимо.
В моем случае нужно было забирать значения из объектов "чужих" классов, таких как std::string. Здесь единственный вариант обеспечения move -- это использование метода swap:
// Этот метод предназначен для случая, когда name заведомо
// временный объект и никогда больше не потребуется.void some_my_class_t::append_name( std::string & name )
{
// Добавление пустой строки должно быть эффективной
// операцией, т.к. никаких данных в строке не копируется.
m_name_list.push_back( std::string() );
// А вот теперь делаем move в пустой только что
// добавленный объект.
m_name_list.last().swap( name );
}
Проблема здесь в том, что код, использующий поддобный append_name, не прозрачен при чтении:
std::string name = .../* формирование очередного имени */
my_object.append_name( name );
... // Нигде не было указаний, что значения в name больше нет :(
Более того, если в some_my_class_t есть два метода append_name (для константной и неконстантной ссылок), то программист может по ошибке посчитать, что он вызвает append_name для константной ссылки и попытаться использовать name после обращения к append_name.
Но, если то же самое записать с помощью temporary_object_ref_t, то код оказывается прозрачнее:
std::string name = .../* формирование очередного имени */
my_object.append_name( make_temporary_object_ref( name ) );
Здесь намерения программиста сразу же явно декларируются.
Но, что самое хорошее, так это то, что можно использовать уже готовые чужие типы (вроде stl-еских строк и контейнеров), которые имеют только swap и ничего не хотят знать про существующие фреймворки для обеспечения move-семантики.
Т.е. я в своем коде использую хоть и легальные, но все-таки хаки. И это явным образом подчеркивается.
E>>А вот фреймворки для поддержки move-семантики, имхо, тупиковый путь. Здесь должно быть стандартное решение в самом языке, а не в виде библиотек.
_>Возможно. Но, пока в самом языке этого нет, алтернативных решений кроме библиотек я не вижу.
А библиотечные решения здесь вообще не катят, имхо. Разве что, если какой-нибудь boost::move будет включен в tr2. А до тех пор разработчики универсальных библиотек, которые захотят давать своим типам move-семантику, будут вынуждены ориентироваться на какой-то конкретный move-фреймворк. А это сделает недоступной move-семантики с другими move-фреймворками.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, sergey_shandar, Вы писали:
E>>>Я свое примитивное решение сделал только для того, чтобы явно помечать в коде места, в которых производится оптимизация посредством изымания значения из временного объекта. Для моих конкретных нужд этого хватило.
_>>На самом деле, cbear_berlios_de::move::t<T> и есть тот самый врап, который помечает в коде те самые места Все остальное, это описание возможностей
E>... Как я понял, ваша реализация расчитана на перемещение объектов, у которых есть метод move_assign. ... В моем случае нужно было забирать значения из объектов "чужих" классов, таких как std::string. Здесь единственный вариант обеспечения move -- это использование метода swap.
Не обязательно. Дело в том, что для уже существующего типа T можно определить свой move::traits<T>::assign. Сначала я использовал std::swap или O.swap. Но это не всегда приемлимо. Например, для std::vector возможно это оптимальная реализация, а для boost::array оптимальный move будет совсем другой.
Так что, выводы о неприменимости к чужим типам не верны, соотвественно и взгляд на библиотечные реализации.
E>Но, если то же самое записать с помощью temporary_object_ref_t, то код оказывается прозрачнее: E>
E>std::string name = .../* формирование очередного имени */
E>my_object.append_name( make_temporary_object_ref( name ) );
E>
E>Здесь намерения программиста сразу же явно декларируются.
C cbear это выглядит практически также:
std::string name = ...;
my_object.append_name(move::ref(name));
То есть, move нужно специфицировать обязательно. Это даже не обсуждается. Другой дело, что полезно не только передавать move ссылки как параметры, но иногда и возвращать временные объекты:
Здравствуйте, sergey_shandar, Вы писали:
E>>... Как я понял, ваша реализация расчитана на перемещение объектов, у которых есть метод move_assign. ... В моем случае нужно было забирать значения из объектов "чужих" классов, таких как std::string. Здесь единственный вариант обеспечения move -- это использование метода swap.
_>Не обязательно. Дело в том, что для уже существующего типа T можно определить свой move::traits<T>::assign. Сначала я использовал std::swap или O.swap. Но это не всегда приемлимо. Например, для std::vector возможно это оптимальная реализация, а для boost::array оптимальный move будет совсем другой.
Это не значит, что cbear::move поддерживат перемещение для std::string. А всего лишь то, что пользователь может обеспечить адаптацию cbear::move для std::string. Несколько разные вещи, имхо. Тем более, что не все с ходу догадаются, что нужно переопределять move::traits<T>::assign. Можно же еще и move::assign для своих типов переопределить.
_>Так что, выводы о неприменимости к чужим типам не верны, соотвественно и взгляд на библиотечные реализации.
Библиотечные реализации, в моем представлении, ведут к появлению кода вида:
class some_my_class_t {
public :
#if defined( USE_CBEAR )
void append_name( cbear_berlios_de::move::t< std::string > name );
#elif defined( USE_ADOBE )
void append_name( adobe::move_from< std::string > name );
#elif defined( USE_BOOST )
void append_name( boost::move_from< std::string > name );
#endif
...
};
Может вам это и кажется приемлимым подходом.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, sergey_shandar, Вы писали:
E>>>... Как я понял, ваша реализация расчитана на перемещение объектов, у которых есть метод move_assign. ... В моем случае нужно было забирать значения из объектов "чужих" классов, таких как std::string. Здесь единственный вариант обеспечения move -- это использование метода swap.
_>>Не обязательно. Дело в том, что для уже существующего типа T можно определить свой move::traits<T>::assign. Сначала я использовал std::swap или O.swap. Но это не всегда приемлимо. Например, для std::vector возможно это оптимальная реализация, а для boost::array оптимальный move будет совсем другой.
E>Это не значит, что cbear::move поддерживат перемещение для std::string. А всего лишь то, что пользователь может обеспечить адаптацию cbear::move для std::string. Несколько разные вещи, имхо.
Именно так. Я и не утверждал что cbear поддерживает std::string (оно и не надо, если есть основательная причина — то можно поддержать). Зато я утверждал что использовать X.swap() или std::swap для move совсем даже не правильно. Скорее на это нужно обратить внимание.
E>Тем более, что не все с ходу догадаются, что нужно переопределять move::traits<T>::assign. Можно же еще и move::assign для своих типов переопределить.
Да, документация нужна.
_>>Так что, выводы о неприменимости к чужим типам не верны, соотвественно и взгляд на библиотечные реализации.
E>Библиотечные реализации, в моем представлении, ведут к появлению кода вида: E>
Зачем в проекте использовать близкие по смысле сущности из разных библиотек? Нужно остановиться на чем то одном. То же самое можно сказать про контейнеры, строки, умные указатели. Ну если уж действительно нужно, то хотя бы просто определи move_string для разных библиотек. И потом используй:
class some_my_class_t
{
public:
void append_name(move_string const &name);
};
Здравствуйте, sergey_shandar, Вы писали:
_>Именно так. Я и не утверждал что cbear поддерживает std::string (оно и не надо, если есть основательная причина — то можно поддержать). Зато я утверждал что использовать X.swap() или std::swap для move совсем даже не правильно. Скорее на это нужно обратить внимание.
В случае, когда нужно реализовать move для чужих типов, у которых есть только swap (как в std::string), выбора у разработчика нет. И не важно, будет ли разработчик сам вызывать у X.swap() или же он переопределит move::assign с использованием X.swap -- все равно без swap не обойтись. Об этом я и сказал.
А std::swap для move -- это вообще нонсенс, имхо.
_>Зачем в проекте использовать близкие по смысле сущности из разных библиотек? Нужно остановиться на чем то одном.
Представим себе ситуацию -- я разрабатываю некую библиотеку. И мне потребовалось в нескольких местах использовать move. Я могу взять, скажем, cbear_berlios_de. И заставлять своих пользователей качать ее для того, чтобы скомпилировать мою библиотеку.
После чего кто-нибудь из пользователей скажет: мы не можем использовать cbear_berlios_de по таким-то и таким-то причинам. Можно ли создать адаптацию под Adobe-вскую библиотеку? Мне таких пользователей посылать?
>То же самое можно сказать про контейнеры, строки, умные указатели.
Именно, поэтому-то контейнеры и строки входят в стандартную библиотеку. И поэтому туда собираются добавить умные указатели.
>Ну если уж действительно нужно, то хотя бы просто определи move_string для разных библиотек. И потом используй: _>
Здравствуйте, eao197, Вы писали:
_>>Зачем в проекте использовать близкие по смысле сущности из разных библиотек? Нужно остановиться на чем то одном.
E>Представим себе ситуацию -- я разрабатываю некую библиотеку. И мне потребовалось в нескольких местах использовать move. Я могу взять, скажем, cbear_berlios_de. И заставлять своих пользователей качать ее для того, чтобы скомпилировать мою библиотеку.
1. Более того, cbear завязанна на boost. В cbear стараюсь не использовать велосипедов которые уже есть в std или в boost, до тех пор, пока не нахожу в них какие-то недостатки. Если делаю свой велосипед, стараюсь придерживаться тех же соглашений (например, контейнер должен иметь функции begin, end и т.д.), что бы его можно было впоследствии заменить.
2. Со своей библиотекой ты будешь поставлять свой temporary_object_ref_t< T >? Если да, то почему бы не использовать хотя бы те же соглашения по названиям, которые используются в других библиотеках (boost, cbear)? Можно даже часть кода, даже модифицированного, и boost и cbear под MIT подобной лицензией.
E>После чего кто-нибудь из пользователей скажет: мы не можем использовать cbear_berlios_de по таким-то и таким-то причинам. Можно ли создать адаптацию под Adobe-вскую библиотеку? Мне таких пользователей посылать?
Такой же вопрос они могут задат и по поводу temporary_object_ref.
>>То же самое можно сказать про контейнеры, строки, умные указатели.
E>Именно, поэтому-то контейнеры и строки входят в стандартную библиотеку. И поэтому туда собираются добавить умные указатели.
И используют их до тех пор пока они подходят, а потом делают свои или используют еще чьи то (тупиковые они или нет, пользователям работающая программа нужно сегодня, а не в 0X году). Только, чем больше сущность похожа на стандартную, тем легче сделать этот переход. Например, мне не подходят ни std::wstring, ни std::vector для моих COM DLL, так как конвертировать при каждом вызове COM функции std::wstring в BSTR и std::vector в SAFEARRAY и обратно очень глупое занятие. Поэтому и есть свои com::bstr, com::safearray которые очень похожи на стандартные std::wstring или std::vector, но являются тонкими оболочками над COM типами.
Я к тому, что нужно разговор переводить в конструктивное русло. Т.е. аргументы — вот такой дизайн будет лучше потому-то и потому-то.
>>Ну если уж действительно нужно, то хотя бы просто определи move_string для разных библиотек. И потом используй: _>>
Здравствуйте, sergey_shandar, Вы писали:
_>2. Со своей библиотекой ты будешь поставлять свой temporary_object_ref_t< T >? Если да, то почему бы не использовать хотя бы те же соглашения по названиям, которые используются в других библиотеках (boost, cbear)? Можно даже часть кода, даже модифицированного, и boost и cbear под MIT подобной лицензией.
Да буду, поскольку эта зависимость гораздо меньше, чем зависимость от Boost-а (было бы охринительно притянуть к проекту, который уже использует 8Mb дистрибутив ACE еще и 20Mb дистрибутив Boost-а ради какой-нибудь boost::move ).
А какие названия? move::t или move_from? Почему cbear не использует соглашения из boost-а для move-семантики?
Или речь идет о стиле именования вообще? Так в C++, к счастью, нет стандарта на стиль именования. Boost использует свой, ACE -- свой, Crypto++, Poco и Qt свои. Я использую свой, т.к. мне он удобнее, чем остальные.
E>>После чего кто-нибудь из пользователей скажет: мы не можем использовать cbear_berlios_de по таким-то и таким-то причинам. Можно ли создать адаптацию под Adobe-вскую библиотеку? Мне таких пользователей посылать?
_>Такой же вопрос они могут задат и по поводу temporary_object_ref.
Про temporary_object_ref -- вряд ли, т.к. тут зависимость гораздо более мелкая. Но если зададут, то придется делать адаптации к разным библиотекам.
Хотя, если предложат адаптироваться к Boost-у, то скорее попрошу за такую адаптацию деньги
Или просто пошлю.
_>Я к тому, что нужно разговор переводить в конструктивное русло. Т.е. аргументы — вот такой дизайн будет лучше потому-то и потому-то.
А зачем здесь что-то обсуждать? Я сделал конкретное решение одной конкретной маленькой задачки. Строить из него фреймворк для реализации move-семантики у меня не было желания изначально. Поэтому я просто поделился сделаным и спросил, есть ли что-то подобное. Спросил не зря, т.к. узнал про mojo, cbear, adobe::move и boost::move. Глянул, чуть расширил свой кругозор. Но желания использовать что-то из этого не вознило совершенно. И не потому, что они сделаны плохо, а потому что в данном конкретном случае это из пушки по воробьям.
Так что обсуждать?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[10]: Велосипедик в отсутствии rvalue references
Здравствуйте, sergey_shandar, Вы писали:
_>Можно даже часть кода, даже модифицированного, и boost и cbear под MIT подобной лицензией.
Интересен общий объем кода, который нужно вырезать из boost-а и cbear для того, чтобы использовать move-проект отдельно. Там ведь еще и MPL используется. А за ним и еще что-нибудь подтянется, вроде config или compiler_workarounds.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
).