Программистское абстрактное

[spamsink]

Дано:

using std::string;
string dotted_pair1(const string & a, const string & b) {
    return a + '.' + b;
}
string dotted_pair2(const string & a, const string & b) {
    return (a + '.') += b;
}

Как нетрудно видеть умозрительно, да и экспериментально, dotted_pair2 эффективнее - меньше временных объектов создается. В общем случае компилятор не имеет права делать такую оптимизацию автоматически. Как бы ему объяснить, что в этом конкретном случае он его имеет?

Ну и совсем абстрактно: интересно, программисты на ФЯП в принципе задумываются о зависимости эффективности выполняемого кода от идиоматики исходного, или они выше этих глупостей?

Comments

[rezkiy.livejournal.com]

мне всегда казалось, что как только больше двух слагаемых, надо использовать что-то типа stringstream.

[spamsink]

Если нет форматных преобразований, то из пушки по воробьям будет, да и совершенно неидиоматично.

[rezkiy.livejournal.com]

Надо профайлить.

[spamsink]

Попробую со stringstream чуть позднее. Но так или иначе, в языке полезно иметь возможность явно объявить ассоциативность операции (неважно, как именно выраженной синтаксически), чтобы компилятор мог делать такую оптимизацию, т.е. чтобы, в общем случае, F(F(a,b),c) могло внутри делаться как F(a,b).F(c)

[dvv.livejournal.com]

gcc 4.1.2: апсолютно адинхуй.
gcc 4.7.1: апсолютно адинхуй.

Почему второй вариант вообще проходит — на первый взгляд непонятно.

[spamsink]

И даже глядя на ассемблер - апсолютно?
Я тоже пробовал с опаской, но видимо, потому что r-values нельзя лишь передавать по неконстантным ссылкам, а применять к ним неконстантные методы - можно.

[dvv.livejournal.com]

Именно глядя на ассемблер.

Различия только вот в чём:

В первом случае пускается конструктор на временную строку с аргументом a, к ней цепляется одна точка, и ей же инициируется возврат, к возврату цепляется b. Деструктор на временную строку, выход из функции.

Во втором случае пускается конструктор на временную строку с аргументом a, к ней цепляется одна точка, к ей же цепляется b, ей же инициируется возврат. Деструктор на временную строку, выход из функции.

Возможно, из-за того, что конкатенации (append()) и конструктору приходится работать с разными данными, в профилировании может набежать разница. Но это уже от твоих данных зависит, а не от компилятора.

[mynine.livejournal.com]

А на чем вы тестировали?
Я проверил VC2010 - практически идентичные варианты. По числу объектов совершенно одинаковые - один временный, где конкатенируются строки. Разница только в том что во втором случае временный объект создается явно внутри функции, а в первом через move внутри второго оператора конкатенации.

[dvv.livejournal.com]

В общем случае это так и есть. F(F(a,b),c) с точки зрения реализации ничем не отличается от, грубо говоря, a.F(b).F(c).

[spamsink]

a - в данном случае константа, к ней нельзя неконстантный метод применять.

[dvv.livejournal.com]

Ключевая фраза — "грубо говоря".

[mynine.livejournal.com]

Чуть поторопился - в обоих случаях все-таки два объекта генерятся.

[cema.livejournal.com]

В каком смысле исходного?

[mynine.livejournal.com]

В данном случае (обоих примерах) конкатенация не метод, а свободная функция operator+() с константными параметрами. И с ней поэтому все проходит нормально.

[spamsink]

Я тестировал на GCC 4.4. По идее на C++11 можно выразить эту идею, объявив оператор конкатенации 4 раза: со всеми комбинациями обычных ссылок и rvalue ссылок (которого у нас еще не установлено), но я задумался, нельзя ли выразить это более изящно.

[spamsink]

В смысле - текста на ФЯП, написанного программистом.

[spamsink]

Именно глядя на ассемблер.

конкатенации (append()) и конструкторам приходится работать с разными данными, в профилировании может набежать разница.

О том и речь. И разница всегда будет в пользу второго случая. У меня на GCC 4.4.0 на моем тесте 10%.

В 4.7, наверное, уже вовсю C++11 с rvalue references, но это ж с дуба можно рухнуть все комбинации аргументов выписывать. Мой вопрос вот в чём: неужели ничего более удобного нельзя в языке придумать, чтобы объяснить компилятору, чё те надо?

[mynine.livejournal.com]

это видимо в гнуси, в вижуале разворачиватся так (аргументы шаблона я выкинул для удобочитаемости - они const):

a + '.' + b => operator+(operator+(a, '.'), b)
(a + '.') += b => (operator+(a,'.')).operator+=(b)

[spamsink]

Так вот почему бы не сделать так, чтобы можно было однажды объяснить, что
F(const a, b) ≡ unique_copy(a).F(b), а не через повторения одного и того же с помощью rvalue references? Бешеная репликация кода в инклюдах задолбала.

[mynine.livejournal.com]

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

[dvv.livejournal.com]

Если у тебя такие данные, и важен порядок действий, то нужно не выёбываться, а указывать оный порядок действий:

string dotted_pair(const string & a, const string & b) {
    string tmp(a);
    return tmp.append(1, '.').append(b);
}

Или для любителей one-liners и obfuscation:

string dotted_pair(const string & a, const string & b) {
    return (a + '.').append(b);
}

Временных объектов и конструторов/деструкторов во всех четырёх случаях ровно одинаково.

[mynine.livejournal.com]

То, что я выше привел, (для первого примера) именно через rvalue ref реализовано.
внешний оператор конкатенации с сигнатурой :
string operator+(string&&, const string&)

[mynine.livejournal.com]

уж лучше так ;)

string dotted_pair(const string & a, const string & b) {
return string(a).append(1, '.').append(b);
}

по объектам опять все едино, но теоретически append() чуть быстрее, потому что не обернут снаружи оператором. Хотя скорее всего, при оптимизации все это и так уберется

[dvv.livejournal.com]

Это, видимо, цитата из стандарта. Но я отвечал не на тот вопрос, поэтому комментарий убран.

[dvv.livejournal.com]

Это не "скорее всего", это уберётся в первую очередь.