Должны ли неявно сгенерированные операторы присваивания быть & ref-квалифицированными?

Следующий код компилируется без проблем на gcc 4.8.1:

#include 

struct foo
{
};

int main()
{
    foo bar;

    foo() = bar;
    foo() = std::move( bar );
}

Кажется, неявно сгенерированные операторы присваивания дляfoo не& ref-qualified и может быть вызван на rvalues. Это правильно в соответствии со стандартом? Если так, то какая причина дляне требующий неявно сгенерированных операторов присваивания быть& иая квалификация?

Почему нетСтандарт требует, чтобы было сгенерировано следующее?

struct foo
{
  foo & operator=( foo const & ) &;

  foo & operator=( foo && ) &;
};
 Luc Danton08 июн. 2013 г., 10:20
Имейте в виду, что до появления C ++ 11 существовали неявные операторы присваивания копии, и, следовательно, до появления ref-определителей для нестатических функций-членов. Это и философия Стандартного комитета, когда дело доходит до компиляции прежнего кода C ++ с более новым компилятором.
 Andrew Durward08 июн. 2013 г., 15:15
@Luc По какой-то причине обратная совместимость не сработалане происходит со мной до тех пор, пока яЯ разместил вопрос. Я'я забыл, что типичный анализ затрат / выгод неПрименять при рассмотрении изменений в стандарте.

Ответы на вопрос(2)

Решение Вопроса

есть определенные законные варианты использования для присвоения rvalue. Цитировать изRef-квалификаторы для операторов присваивания в стандартной библиотеке:

Есть только несколько очень специфических типов, для которых имеет смысл поддерживать присвоение rvalue. В частности, типы, которые служат в качестве прокси, например, вектор <BOOL>:: ссылка и типы, операторы присваивания которых являются константными (например, slice_array).

Комитет по стандартизации C ++, очевидно, считал, что задание по умолчанию не должно иметь неявный ref ref, скорее это должно бытьявно заявлено, Действительно, может существовать код, который перестал бы работать, если вдруг все неявно объявленные операторы присваивания не 'работать со значениями

Конечно, этоНемного сложно придумать пример, в котором мы хотим, чтобы неявно объявленный оператор присваивания работал с r-значениями, но стандартный комитет C ++, вероятно, неЯ не хочу рисковать, когда речь идет о сохранении обратной совместимости. Код как это:

int foo_counter = 0;

struct Foo
{
    Foo()
    {
        ++foo_counter;
    }

    ~Foo()
    {
        --foo_counter;
    }
};

int main()
{
    Foo() = Foo();
}

... Wouldn»больше не работает. И в конце концов, комитет по стандартам хочет убедиться, что ранее действующий C ++ (независимо от того, насколько он глупый или надуманный) продолжает работать в C ++ 11.

 Andrew Durward08 июн. 2013 г., 12:58
Кажется, ониМы применили ту же логику (re: обратная совместимость) к связанному предложению, так как проблема была закрыта как "не дефект ".  Так что все случаиstd::string() = std::string() останется в силе (к лучшему или к худшему).

Почему назначение на значение всегда будет полезным? " скорее, чем "Почему нетt стандартные сгенерированные конструкторы ref-qualify? "

Причиной присваивания rvalue является то, что в некоторых случаях это полезно.

Один пример использования сstd::tie (ссылка на сайт):

#include <set>
#include <tuple>

int main()
{
    std::set<int> s;

    std::set<int>::iterator iter;
    bool inserted;

    // unpacks the return value of insert into iter and inserted
    std::tie(iter, inserted) = s.insert(7);
}
</int></int></tuple></set>

Пример заимствован из cppreference.com, затем изменен

 Timothy Shields08 июн. 2013 г., 05:10
@CharlesSalvia Хм, может быть, выверно. Я спешно ответил и немного неправильно понял вопрос. Ваш ответ более прямо отвечает на него.
 Charles Salvia08 июн. 2013 г., 05:08
Это нена самом деле не отвечает на вопрос, потому что OP специально задает неявно объявленные операторы присваивания, а не присваивает их значениям вообще

Ваш ответ на вопрос