С ним банально неудобно работать. Один из кейсов, пусть и редких — набить с помощью вектора массив данных и скормить вместе с владением какой-нибудь функции.
Если вы таскаете по стеку структуру на 100500 полей, вы делаете что-то не так. А мув служит для почти бесплатного перемещения контейнеров, у которых маленьая часть на стеке и большая в куче. Простой пример — вектор на пару сотен килобайт. Без мува, при отдаче владения в функцию, у вас будет копирование. Толстое. С выделением ещё одного куска на пару сотен килобайт и копированием всего содержимого. С мувом — старый вектор отдаст новому владение буфером. И будет "копирование" 1 указателя. С занулением его на старом месте.
Проблема в том, что это просто тяжело осилить одним куском. Это примерно как God Class. Класс, отвечающий за всё и сразу. А помнить о всех тёмных уголках стандарта придётся — даже тем, кому эти мат. функции не нужны.
А я не говорю, что аналитическая геометрия это плохо. Я говорю, что ей место в отдельной либе. Пусть она поддерживается комитетом, не вопрос. Но отдельно. Иначе такими темпами в стандарт захотят 3Д-движок, физический движок, библиотеку акторов и что-нибудь ещё. И тогда стандарт будет не 1600 а 16000 страниц.
Бывает. Впрочем, я не евангелист — так, сочувствующий. Стараюсь если вставлять про Rust, то по теме обсуждения и понемногу. И давайте наверное закрывать эту ветку, а то совсем оффтоп получается.
Это реально "горшочек". Одно только внедрение аналитической геометрии в стандарт. Хотя ей самое место в отдельном пакете. Т.е. в стандарт тащат много, но не всегда то, что реально нужно.
По-моему, аллокация памяти там сильно лишняя. Почему не могут просто отдать буфер? Ведь, по сути, recursive_wrapper почти то же самое, что и unique_ptr.
Все просто: move semantics придумали чтобы сделать нормальные умные указатели. К примеру, uniqie_ptr без семантики перемещения нельзя было бы использовать в STL-контейнерах.
Не только для них. Чтобы не иметь копирований на ровном месте, где их быть не должно.
Проблема в том, что в общем случае очень трудно определить, какая категория итераторов пришла. Да просто нет возможности поставить ограничение «здесь принимается random access iterator».
Плюс, ограничение на тип элемента делается криво.
Плюс, функции, принимающие итератор, обязаны быть шаблонными — а принимающие срез конкретного типа — нет.
Вообще-то в rvalue reference превращаются только rvalue. А 'foo& bar' — lvalue. Здесь как раз косяков нет. Хотите переместить именованное значение — std::move. Но если после него вы используете старую переменную — ССЗБ.
Это, простите, капец. По-моему, это PL/1 v2 уже какой-то.
Хотя, с другой стороны, заставить всех использовать единый формат пакетов и проектов можно только жёстко впилив его в стандарт. Но этого не будет никогда — потому что MS, Google, GCC team будут вечно тянуть одеяло на себя.
/fanboy mode on
Хочу только одну вещь. Поддержку в Rust'е импорт C headers из коробки. После этого "два крестика" покатится cо всё нарастающей скоростью.
С ним банально неудобно работать. Один из кейсов, пусть и редких — набить с помощью вектора массив данных и скормить вместе с владением какой-нибудь функции.
Если вы таскаете по стеку структуру на 100500 полей, вы делаете что-то не так. А мув служит для почти бесплатного перемещения контейнеров, у которых маленьая часть на стеке и большая в куче. Простой пример — вектор на пару сотен килобайт. Без мува, при отдаче владения в функцию, у вас будет копирование. Толстое. С выделением ещё одного куска на пару сотен килобайт и копированием всего содержимого. С мувом — старый вектор отдаст новому владение буфером. И будет "копирование" 1 указателя. С занулением его на старом месте.
Проблема в том, что это просто тяжело осилить одним куском. Это примерно как God Class. Класс, отвечающий за всё и сразу. А помнить о всех тёмных уголках стандарта придётся — даже тем, кому эти мат. функции не нужны.
А я не говорю, что аналитическая геометрия это плохо. Я говорю, что ей место в отдельной либе. Пусть она поддерживается комитетом, не вопрос. Но отдельно. Иначе такими темпами в стандарт захотят 3Д-движок, физический движок, библиотеку акторов и что-нибудь ещё. И тогда стандарт будет не 1600 а 16000 страниц.
Бывает. Впрочем, я не евангелист — так, сочувствующий. Стараюсь если вставлять про Rust, то по теме обсуждения и понемногу. И давайте наверное закрывать эту ветку, а то совсем оффтоп получается.
Это реально "горшочек". Одно только внедрение аналитической геометрии в стандарт. Хотя ей самое место в отдельном пакете. Т.е. в стандарт тащат много, но не всегда то, что реально нужно.
По-моему, аллокация памяти там сильно лишняя. Почему не могут просто отдать буфер? Ведь, по сути, recursive_wrapper почти то же самое, что и unique_ptr.
Так я тоже писал, что возможно — но неудобно.
Сравните с
Там ЕМНИП самая большая проблема осталась — макро константы. Но не будем здесь разводить оффтоп.
Не только для них. Чтобы не иметь копирований на ровном месте, где их быть не должно.
Плюс, ограничение на тип элемента делается криво.
Плюс, функции, принимающие итератор, обязаны быть шаблонными — а принимающие срез конкретного типа — нет.
В общем, пользоваться можно — но срезы удобней.
Rust вообще-то. Почитайте на досуге, если интресно. Там, в частности, исправлены многие косяки С++.
Нет, я не про то. Я про возможность отобрать владение таким буфером и отдать кому-то ещё.
Кстати, из чистого интереса. std::vector, std::string научились конструироваться из сырого буфера и отдавать свой сырой буфер?
Вот кстати не могу представить throwing move. Подкинете пример?
Не-а. Надо как раз забыть у статик-переменной дописать static, который сделает ей локальную видимость.
Это, простите, капец. По-моему, это PL/1 v2 уже какой-то.
Хотя, с другой стороны, заставить всех использовать единый формат пакетов и проектов можно только жёстко впилив его в стандарт. Но этого не будет никогда — потому что MS, Google, GCC team будут вечно тянуть одеяло на себя.
/fanboy mode on
Хочу только одну вещь. Поддержку в Rust'е импорт C headers из коробки. После этого "два крестика" покатится cо всё нарастающей скоростью.