RD>void func(int&&) noexcept {
RD>}
RD>int main() {
RD> int x = 10;
RD> func(x); // error: cannot bind 'int' lvalue to 'int&&'
RD>}
RD>
RD>
RD>// template< class T >
RD>// typename std::remove_reference<T>::type&& move( T&& t ) noexcept;
RD>int main() {
RD> int x = 10;
RD> std::move(x); // OK
RD>}
RD>
RD>Почему std::move принимает x, а func нет?
Компилятор чётко объясняет, почему.
// error: cannot bind 'int' lvalue to 'int&&'
Если хочешь вызвать func с lvalue, используй std::move :
Здравствуйте, rain.drop, Вы писали:
RD>Почему std::move принимает x, а func нет?
Объяви func шаблонной, как move, она тоже начнет принимать все, что угодно:
template <typename T>
void func(T&&) noexcept {}
Потому, что в шаблонном варианте мы имеем дело не с rvalue reference, пусть тебя не обманывает внешняя похожесть, а с особым видом ссылок, называемых forwarding references. Которые способны забиндить на себя вообще все, что угодно, в виду их всеядности.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rain.drop, Вы писали:
RD>Почему std::move ...?
Еще один изучает C++14 . std::move интересен только некоторым C++-фрикам, практической пользы же никакой в язык не приносит. Если тебе нужны 3% скорости, управляй памятью вручную, учи ассемблер, и не страдай из-за выдумок фанатиков из C++ комитета.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Здравствуйте, rain.drop, Вы писали:
RD>>Почему std::move ...?
lpd>Еще один изучает C++14 . std::move интересен только некоторым C++-фрикам, практической пользы же никакой в язык не приносит.
Позвольте НЕ согласиться. Практическая польза — в виде экономии памяти (переносим, вместо того, чтобы копировать) — налицо.
lpd>Если тебе нужны 3% скорости, управляй памятью вручную, учи ассемблер, и не страдай из-за выдумок фанатиков из C++ комитета.
Это требования жизни и развития языка C++ в наше время. То, что Вы предлагаете — это вариант скорее для embedded приложений, нежели для общепринятого C++ мейнстрима.
Ну и вариант, когда только один волшебник разработчик может понять проект, к чему неминуемо приведёт предлагаемый Вами подход, — это путь в никуда
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, lpd, Вы писали:
lpd>>Здравствуйте, rain.drop, Вы писали:
RD>>>Почему std::move ...?
lpd>>Еще один изучает C++14 . std::move интересен только некоторым C++-фрикам, практической пользы же никакой в язык не приносит. AG> AG>Позвольте НЕ согласиться. Практическая польза — в виде экономии памяти (переносим, вместо того, чтобы копировать) — налицо.
Дело вообще не в памяти, а в экономии времени на копировании. Только люди на Java/C# пишут код, который в 3 раза медленнее, поэтому вдвойне глупо расставлять rvalue-reference и std::move, особенно если алгоритм неоптимален, или оптимизируемый код вообще не является узким местом. Не говоря уже о мизерном выигрыше в общем быстродействии, деленном на усложнении кода, являющимися результатом использования этих фич. C++14 можно рассматривать как хобби, хотя мне и непонятное, но не не нужно тащить его в каждый проект, особенно если программисты не знают гораздо более важных вещей.
AG>Это требования жизни и развития языка C++ в наше время.
Стадный инстинкт как он есть.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Дело вообще не в памяти, а в экономии времени на копировании. Только люди на Java/C# пишут код, который в 3 раза медленнее, поэтому вдвойне глупо расставлять rvalue-reference и std::move, особенно если алгоритм неоптимален, или оптимизируемый код вообще не является узким местом. Не говоря уже о мизерном выигрыше в общем быстродействии, деленном на усложнении кода, являющимися результатом использования этих фич. C++14 можно рассматривать как хобби, хотя мне и непонятное, но не не нужно тащить его в каждый проект, особенно если программисты не знают гораздо более важных вещей.
Дело вообще не в оптимизации, а в том, что перемещение как концепция должно быть явно выражено средствами языка. Концепция перемещения существует вне зависимости от того, находишь ты ее лишней или нет. Как 0 в математике. О том, что он есть, тоже не сразу догадались. Например, есть алгоритмы, где пустая ячейка путешествует по массиву, как дырка в полупроводнике. Язык без перемещений не позволяет явно выразить такую семантику. Да даже простейший swap — это по сути ни разу не копирования, а именно перемещения — ты ж просто меняешь вещи местами. Когда в жизни барахло перемещаешь, тоже создаешь же какие-то копии?
lpd>Стадный инстинкт как он есть.
. Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий(с). А ты свой взгляд через амбразуру тут безапелляционно выдаешь за пример высшей мудрости.
Здравствуйте, T4r4sB, Вы писали:
TB>Внимание вопрос — можно ли это сделать, не подключая СТЛ?
Можно. static_cast-ом шарахнуть по конкретному объекту, про который ты знаешь, что он точно lvalue. В принципе и свой move достаточно просто завелосипедить, только еще придется и remove_reference написать, что тоже несложно. Кроме remove_reference и static_cast внутри и нет ничего.
Здравствуйте, T4r4sB, Вы писали:
Ш>>Если хочешь вызвать func с lvalue, используй std::move :
TB>Внимание вопрос — можно ли это сделать, не подключая СТЛ?
Ну, коль скоро требования к функции move известны, более того зафиксированы в стандарте, я не вижу препятствий тому, чтоб реализовать эту функцию, или ее аналог, самостоятельно.
TB>Внимание вопрос — можно ли это сделать, не подключая СТЛ?
Если что-то есть в STL, а точнее в стандартной библиотеке, которая идет с компилятором, то лучше не изобретать велосипед, а использовать стандартную библиотеку. Кроме того, что написанное в std гораздо лучше протестировано, там иногда используют интринсики компилятора, которые работают быстрее, чем если использовать только возможности языка, описанные в стандарте (SFINAE или рекурсивного инстанциирования шаблонов, например).
Здравствуйте, andyp, Вы писали:
A>Здравствуйте, lpd, Вы писали:
lpd>>Дело вообще не в памяти, а в экономии времени на копировании.
A>Дело вообще не в оптимизации, а в том, что перемещение как концепция должно быть явно выражено средствами языка.
Я в принципе согласен, что перемещение переменных — идея интересная для разработчиков высокоуровнего языка. Но C++ раньше был не сборником интересных теоретических фич. Появись перемещение в каком-нибудь другом языке, не было бы ажиотажа, и большинство не изучало бы тонкости преобразований rvalue-ссылок. "Но раз это в Стандарте C++, то необходимо использовать перемещение как можно чаще, иначе код несовременный." — рассуждают все, от студентов до кадровичек.
Объективно же в тех крайне редких случаях, когда есть смысл оптимизировать копирование какой-нибудь переменной, можно просто напрямую скопировать указатель на данные, по сути сделав то же самое, но без введения новых типов данных в язык.
И точно программисту, знающему C++98, полезнее изучить ассемблер, скрипты, Linux, устройство ОС, алгоритмы, чем вникать в тонкости rvalue-reference.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, lpd, Вы писали:
lpd>Я в принципе согласен, что перемещение переменных — идея интересная для разработчиков высокоуровнего языка. Но C++ раньше был не сборником интересных теоретических фич. Появись перемещение в каком-нибудь другом языке, не было бы ажиотажа, и большинство не изучало бы тонкости преобразований rvalue-ссылок. "Но раз это в Стандарте C++, то необходимо использовать перемещение как можно чаще, иначе код несовременный." — рассуждают все, от студентов до кадровичек. lpd>Объективно же в тех крайне редких случаях, когда есть смысл оптимизировать копирование какой-нибудь переменной, можно просто напрямую скопировать указатель на данные, по сути сделав то же самое, но без введения новых типов данных в язык.
Да уж. Залёты "практиков" как на ладони в дизайне auto_ptr. Пока понятия были слабы, нормальных смартпоинтеров мы не имели. Если любопытно, найди в интернете про дизайн функций max и min. Тоже очень познавательно.
lpd>И точно программисту, знающему C++98, полезнее изучить ассемблер, скрипты, Linux, устройство ОС, алгоритмы, чем вникать в тонкости rvalue-reference.
Здравствуйте, AlexGin, Вы писали:
AG>Ну и вариант, когда только один волшебник разработчик может понять проект, к чему неминуемо приведёт предлагаемый Вами подход, — это путь в никуда
Неконтролируемое применение семантики перемещения позволяет запутать код намного продвинутее, чем ассемблер
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, andyp, Вы писали:
A>Да уж. Залёты "практиков" как на ладони в дизайне auto_ptr. Пока понятия были слабы, нормальных смартпоинтеров мы не имели.
Уж не знаю, кто такие "вы", но я нормальными интрузивными смарт-поинтами пользуюсь года с 1995 где-то...
Ну и вообще COM_ptr уже о-о-о-о-о-о-чень давно придумали. Задолго до STL и стандарта 1998-го года
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Уж не знаю, кто такие "вы", но я нормальными интрузивными смарт-поинтами пользуюсь года с 1995 где-то... E>Ну и вообще COM_ptr уже о-о-о-о-о-о-чень давно придумали. Задолго до STL и стандарта 1998-го года
Ну так auto_ptr тоже вполне себе можно было пользоваться, если забыть, что его копирование таковым не является, но в то же время оно все-таки есть .