Здравствуйте, jazzer, Вы писали:
J>теперь надо подождать, когда на этот топик ответит сам alnsn, и проставиться ему
Я тут.
Кевлин меня убедил, что lexical_cast должен использовать пользовательский operator<< если enum его имеет, теперь вот думаю как обнаружить наличие этого оператора. Пока только получилось обнаружить нешаблонный operator<<. У кого-нибудь есть идеи?
Здравствуйте, Roman Odaisky, Вы писали:
RO>Это всё хорошо, только зачем? Кто-то использует lexical_cast (хоть и удобная штука) в местах, критичных к производительности?
А почему не используют? Может быть, потому, что медленный?
Здравствуйте, korzhik, Вы писали:
K>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, korzhik, Вы писали:
K>>>Здравствуйте,
K>>>http://nasonov.blogspot.com/2006/08/boost-lexicalcast-optimization.html
J>>теперь надо подождать, когда на этот топик ответит сам alnsn, и проставиться ему
K>написал ему, может зайдёт
кстати, его статья на эту тему вышла в свежем номере Overload.
Здравствуйте, alnsn, Вы писали:
A>Здравствуйте, Roman Odaisky, Вы писали:
RO>>Это всё хорошо, только зачем? Кто-то использует lexical_cast (хоть и удобная штука) в местах, критичных к производительности?
A>А почему не используют? Может быть, потому, что медленный?
г-н R.O. усугубил конечно, но в целом суть верна -- убирание lexical_cast в циклах с числом итераций >10^6 дает видимый (местами даже очень) прирост скорости...
но в остальном (для меня лично) lexical_cast архиудобнейшая вещь! Благо что "мест критичных по производительности" в реальной жизни не так много -- поэтому вопрос "зачем" не стоит
Здравствуйте, zaufi, Вы писали:
Z>г-н R.O. усугубил конечно, но в целом суть верна -- убирание lexical_cast в циклах с числом итераций >10^6 дает видимый (местами даже очень) прирост скорости...
К сожалению, прирост скорости при преобразовании из целого в строку на FreeBSD + gcc 3.4.4 был всего в три раза. В-основном за счет конструирования std::locale, и, как я подозреваю (но не проверял), из-за отсутствия оптимизации маленьких строк.
Преобразование цифры в char в шесть раз быстрее.
A conversion from int digit to char has been measured on FreeBSD 6.1.
The test has been compiled with gcc 3.4.4 with -O2 optimization flag
turned on.
#include <boost/lexical_cast.hpp>
int main()
{
int volatile result = 0;
for(int count = 1000000; count > 0; --count)
result += boost::lexical_cast<char>(count % 10);
return result;
}
The next table shows execution times of the test compiled with Boost 1.33.1 and with the patched lexical_cast. The last column is the performance influence of not constructing std::locale and std::numpunct<char> objects and not calling std::numpunct<char>::grouping function. This change is not included into the patch because it is not consistent with the standard output operator for int.
Boost 1.33.1 — 2.012 sec
Patch -0.322 sec
Ratio — 6.24
Patch that ignores locales — 0.083 sec
More common is a conversion to std::string. To measure performance of this conversion, the for body in the test program has been replaced with result += boost::lexical_cast<std::string>(count).size();
The results are:
Boost 1.33.1 — 2.516 sec
Patch — 0.844 sec
Ratio — 2.98
Patch that ignores locales — 0.626 sec
Здравствуйте, alnsn, Вы писали:
A>Кевлин меня убедил, что lexical_cast должен использовать пользовательский operator<< если enum его имеет, теперь вот думаю как обнаружить наличие этого оператора. Пока только получилось обнаружить нешаблонный operator<<. У кого-нибудь есть идеи?
Здравствуйте, MaximE, Вы писали:
ME>Здравствуйте, alnsn, Вы писали:
A>>Кевлин меня убедил, что lexical_cast должен использовать пользовательский operator<< если enum его имеет, теперь вот думаю как обнаружить наличие этого оператора. Пока только получилось обнаружить нешаблонный operator<<. У кого-нибудь есть идеи?
ME>http://groups.google.com/group/comp.lang.c++.moderated/msg/8235a058359911dc
Пока внимательно не смотрел, но дело в том, что все enums типы являются printable типами. Если нет пользовательского operator<<, то производится promotion до интегрального типа, для которого есть operator<< член класса basic_ostream<>. Это усложняет задачу
Здравствуйте, alnsn, Вы писали:
A>Здравствуйте, MaximE, Вы писали:
ME>>Здравствуйте, alnsn, Вы писали:
A>>>Кевлин меня убедил, что lexical_cast должен использовать пользовательский operator<< если enum его имеет, теперь вот думаю как обнаружить наличие этого оператора. Пока только получилось обнаружить нешаблонный operator<<. У кого-нибудь есть идеи?
ME>>http://groups.google.com/group/comp.lang.c++.moderated/msg/8235a058359911dc
A>Пока внимательно не смотрел, но дело в том, что все enums типы являются printable типами. Если нет пользовательского operator<<, то производится promotion до интегрального типа, для которого есть operator<< член класса basic_ostream<>. Это усложняет задачу
Тогда screw Kevlin с его долбаными enum'ами, пусть юзеры их структуринами оборачивают.
Здравствуйте, MaximE, Вы писали:
ME>Тогда screw Kevlin с его долбаными enum'ами, пусть юзеры их структуринами оборачивают.
Нешаблонный operator<< я уже умею определять, осталось шаблонный. Может быть как-то сыграть на том, что шаблонная функция имеет более низкий приоритет или попытаться спрятать операторы члены класса basic_ostream<> ?
Здравствуйте, alnsn, Вы писали:
ME>>Тогда screw Kevlin с его долбаными enum'ами, пусть юзеры их структуринами оборачивают.
A>Нешаблонный operator<< я уже умею определять, осталось шаблонный. Может быть как-то сыграть на том, что шаблонная функция имеет более низкий приоритет или попытаться спрятать операторы члены класса basic_ostream<> ?
Ничего умного в голову не приходит.
Может использовать define, чтобы по-умолчанию enum'ы выводились через operator<<, а если define определен, то как integer?
