Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 19

Тогда пользователь объекта, который вдруг воспользуется функцией getLength, получит неверные сведения. Поэтому нельзя варварски обращаться с объектом, который уже не нужен.

Вообще говоря, можно. Даже стандартная библиотека, которая гарантирует "действительное, но не оговорённое" (valid but unspecified) состояние перемещённого объекта (раздел "Moved-from state of library types" [lib.types.movedfrom]), делает это исключительно по своей доброй воле.
Для обычного объекта вполне достаточно того, что перемещённый объект можно уничтожить (выполнить деструктор) или заново проинициализировать (выполнить любое присвоение).
Потому что в целом было бы странно продолжать нормальную работу с объектами, из которых вытащили все внутренности.

Всего голосов 2: ↑2 и ↓0+2

Немного уточню.


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

Всего голосов 1: ↑1 и ↓0+1
Спасибо, важное замечание! Добавлю в статью.
Комментарий пока не оценивали0

Что если я хочу написать так?


class T
{
public:
    T();
    T( const T& ) = delete;
};

T&& foo()
{
    return T();
}

T&& t = foo();

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


При этом я не хочу разрешать перемещать или копировать объект, или использовать placement new (не хочу руками вызывать деструктор).

Комментарий пока не оценивали0

На секунду появилась мысль написать так:


void bar(T& t)
{
    t.T::T();
}

Но это не вариант, непонятно на что ссылаться. Мне неизвестно как создать объект с выделением памяти и вызовом деструктора, но без вызова конструктора.

Комментарий пока не оценивали0

Парадоксально, что судя по вашей статье именно это и происходит (выделение на стеке вызывающей функции, конструирование в вызываемой функции), но в 2017 году до сих пор нет варианта легализовать данное поведение.


Мы всё ещё делаем вид, что есть какое-то мнимое копирование, сдувая пыль со стандартов 20-летней давности.


Я даже не уверен, что если я напишу конструктор перемещения, то это не сделает ситуацию ещё хуже, вынудив компилятор отказаться от RVO. Это какой-то провал!

Комментарий пока не оценивали0

На всякий случай, чтобы не быть голословным. В main:


main:
        lea     rax, [rbp-17]  //выделили место на стеке
        mov     rdi, rax       //передаем адрес через rdi
        call    foo()

        lea     rax, [rbp-17]
        mov     rdi, rax
        call    T::~T()        //вызов деструктора для того же адреса

теперь смотрим foo:


foo:
        mov     QWORD PTR [rbp-8], rdi  //копирование туда-сюда
        mov     rax, QWORD PTR [rbp-8]
        mov     rdi, rax
        call    T::T()                  //вызов конструктора для адреса
                                        //в rdi в стеке main

Иногда действительно хочется отложенную инициализацию.

Комментарий пока не оценивали0
Фактически я хочу легализовать поведение компилятора, когда место под объект выделяется в стеке вызывающей функции, а вызов конструктора происходит в вызываемой функции.

Это невозможно легализовать средствами языка (синтаксически), поскольку в стандарте C++ стек вообще не упоминается применительно к вызову функций, и компиляторы вольны реализовывать функции, как им угодно.

Однако, в C++17 все будет работать так, как вы хотите, и не иначе: возвращаемые значения будут сразу конструироваться на нужном месте (guaranteed copy elision).
Всего голосов 1: ↑1 и ↓0+1

Хороший комментарий. Вот, что интересно: если вы разбирались с этим — заданы ли четкие требования к работе copy elision? Например, в таком случае:


T foo()
{
    T t;
    if (rand() % 2)
    {
        T t;
        return t;
    }
    else
    {
        return t;
    }
}
Комментарий пока не оценивали0
Для возвращаемого значения copy elision делается для RVO
auto foo() -> T { return T{}; }


и для NRVO
auto foo() -> T { T t; return t; }


В вашем случае copy elision скорее всего сделан не будет.
Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь
Мне вот что интересно — если бы язык С++ можно было проектировать с нуля, не оглядываясь на «обратную совместимость», то как бы следовало спроектировать rvalue references? Так как сделано сейчас или как-то иначе?
Комментарий пока не оценивали0

Вероятно, как в Rust.

Всего голосов 3: ↑3 и ↓0+3

Как раз недавно задумывался про это. В смысле, в расте всё удобно сделано, но задать своё "поведение перемещения" нельзя. Интересно можно ли придумать не сильно извращённую логику, когда этого в языке будет не хватать. Я так сходу не смог.

Комментарий пока не оценивали0
Мне нравится cpp тем, что в нем новые фичи реализованы средствами самого языка, как например, в тексте выше реализация std::move по сути каст к rvalue через иснтанцирование нужной специализации remove_reference. Но все это негативно сказывается на время компиляции… И вот скажите, как бы улучшилось время компиляции, если бы std::move был чем-то вроде зарезервированного компилятором имени, и преобразования делались на уровне парсера кода?
Комментарий пока не оценивали0
НЛО прилетело и опубликовало эту надпись здесь
Так помимо приведения типа здесь также есть инстанцирование шаблона, что уже влияет существенно на время компиляции
Комментарий пока не оценивали0
НЛО прилетело и опубликовало эту надпись здесь
Прям так сходу, с графиками и примерами не смогу. Но основываюсь на своем опыте и опыте коллег, которые жалуются, что с обильным использованием шаблонов в С++, время компиляции существенно вырастает. И сами посудите, вот такое неявное использование шаблонов в std::move при использовании его на большом кол-ве различных типов (а это в контексте использования std::move добиться, в приницпе, легко) генерит кучу дополнительного кода. На каждый уникальный тип объекта по инстансу remove_reference, когда могли бы просто получить подстановку нужного типа простой подменой на уровне парсинга кода.
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr