C++ 0x rvalue ссылки - lvalues-rvalue привязка

Это - последующий вопрос C++ 0x rvalue ссылки и временные файлы

В предыдущем вопросе я спросил, как этот код должен работать:

void f(const std::string &); //less efficient
void f(std::string &&); //more efficient

void g(const char * arg)
{
    f(arg);
}

Кажется, что перегрузку перемещения нужно, вероятно, назвать из-за неявного временного файла, и это происходит в GCC, но не MSVC (или фронтенд EDG, используемый в Intellisense MSVC).

Что относительно этого кода?

void f(std::string &&); //NB: No const string & overload supplied

void g1(const char * arg)
{
     f(arg);
}
void g2(const std::string & arg)
{
    f(arg);
}

Кажется что, на основе ответов на мой предыдущий вопрос та функция g1 законно (и принят GCC 4.3-4.5, но не MSVC). Однако GCC и MSVC оба отклонения g2 из-за пункта 13.3.3.1.4/3, который мешает lvalues связывать с rvalue касательно аргументов. Я понимаю объяснение позади этого - оно объяснено в N2831 "Фиксацию проблем безопасности с rvalue ссылками". Я также думаю, что GCC, вероятно, реализует этот пункт, как предназначено авторами той статьи, потому что исходный патч к GCC был записан одним из авторов (Doug Gregor).

Однако я не делаю это довольно интуитивно. Мне, (a) a const string & концептуально ближе к a string && чем a const char *, и (b) компилятор мог создать временную строку в g2, как будто это было записано как это:

void g2(const std::string & arg)
{
    f(std::string(arg));
}

Действительно, иногда конструктор копии считается неявным оператором преобразования. Синтаксически, это предлагается формой конструктора копии, и стандарт даже упоминает это конкретно в пункте 13.3.3.1.2/4, где конструктору копии для преобразований полученной основы дают более высокий разряд преобразования, чем другие пользовательские преобразования:

Преобразованию выражения типа класса к тому же типу класса дают разряд Точного совпадения, и преобразованию выражения типа класса к базовому классу того типа дают разряд Преобразования, несмотря на то, что конструктора копии/перемещения (т.е. пользовательская функция преобразования) вызывают для тех случаев.

(Я предполагаю, что это используется при передаче производного класса функции как void h(Base), который посещает базовый урок значением.)

Мотивация

Моя мотивация для выяснения у этого является чем-то как вопрос, который задают в том, Как уменьшить избыточный код при добавлении нового C++ 0x rvalue перегрузки ссылочного оператора ("Как уменьшить избыточный код при добавлении нового C++ 0x rvalue перегрузки ссылочного оператора").

Если у Вас есть функция, которая принимает много потенциально подвижных аргументов и переместила бы их, если она может (например, функция/конструктор фабрики: Object create_object(string, vector, string) и т.п.), и хочу переместить или скопировать каждый аргумент как соответствующий, Вы быстро начинаете писать много кода.

Если типы аргумента подвижны, то можно было просто записать одну версию, которая принимает аргументы значением, как выше. Но если аргументами являются (наследие) non-movable-but-swappable классы а-ля C++ 03, и Вы не можете изменить их, затем писание rvalue ссылочные перегрузки более эффективно.

Таким образом, если бы lvalues действительно связывал с rvalues с помощью неявной копии, то Вы могли записать всего одну перегрузку как create_object(legacy_string &&, legacy_vector &&, legacy_string &&) и это более или менее работало бы как обеспечение всех комбинаций rvalue/lvalue ссылочных перегрузок - действительные аргументы, которые были lvalues, скопировать и затем связал с аргументами, действительные аргументы, которые были rvalues, станут непосредственно связанными.

Разъяснение/редактирование: Я понимаю, что это фактически идентично принятию аргументов значением для подвижных типов, как C++ 0x станд.:: строка и станд.:: вектор (сохраняют для количества раз конструктора перемещения, концептуально вызывается). Однако это не идентично для copyable, но неподвижных типов, который включает весь C++ 03 класса с явно определенными конструкторами копии. Рассмотрите этот пример:

class legacy_string { legacy_string(const legacy_string &); }; //defined in a header somewhere; not modifiable.

void f(legacy_string s1, legacy_string s2); //A *new* (C++0x) function that wants to move from its arguments where possible, and avoid copying
void g() //A C++0x function as well
{
    legacy_string x(/*initialization*/);
    legacy_string y(/*initialization*/);

    f(std::move(x), std::move(y));
}

Если g вызовы f, затем x и y был бы скопирован - я не вижу, как компилятор может переместить их. Если f были вместо этого объявлены как взятие legacy_string && аргументы, это могло избежать тех копий, где вызывающая сторона явно вызвала std::move на аргументах. Я не вижу, как они эквивалентны.

Вопросы

Мои вопросы затем:

1. Действительно ли это - допустимая интерпретация стандарта? Кажется, что это не стандартное или предназначило один, во всяком случае.
2. Это имеет интуитивный смысл?
3. Существует ли проблема с этой идеей что я "m, не видя? Кажется, что Вы могли получить копии, бесшумно создаваемые, когда это точно не ожидается, но это - статус-кво в местах в C++ 03 так или иначе. Кроме того, это сделало бы некоторые перегрузки жизнеспособными, когда они в настоящее время не, но я не вижу, что он проблемой на практике.
4. Действительно ли это - достаточно значительное улучшение, которое стоило бы сделать, например, экспериментальный патч для GCC?