- 1
- 2
- 3
- 4
- 5
string toString( int i ) {
stringstream s;
s << i;
return s.str();
}-
C++ / Говнокод #11744
+22
Наткнулся на эту функцию в одном из своих старых проектом.
Запостил:
Fai,
11 Сентября 2012
Follow us!
boost::lexical_cast вроде бы так и реализован.
Но вот скорее всего оно не нужно, т.к. в большинстве случаев из подобных кусочков пособирают сложную строку, и лучше там и вставить стрингстрим (будет пошустрее, не намного длиннее, и можно будет управлять форматированием):
думал, распиаренный спирит всех уделаетнадо бы как-нибудь буст 1.51 уже поставить на свой комп и поиграться с ключами оптимизаций
http://tinodidriksen.com/2010/02/07/cpp-convert-int-to-string-speed/
И да, boost::spirit самый тормозной (как до времени компиляции, так и выполнения) генератор парсеров, из всех что я видел. А знаешь почему? Потому что его написали через одно место. Вместо того, чтобы генерировать код, условно говоря, машины состояний, чтобы он работал очень быстро, они написали его на основе комбинаторов. Конечно же получилось такое же тормозное говно, как и Parsec из Хаскеля. А все почему? Потому что кресты не могут в кодогенерацию в отличии от какого-нибудь D или Nemerle (где парсеры быстрые) или специальных кодогенерящих утилит генераторов парсеров ОЛОЛОЛ КРЕСТОПРОБЛЕМЫ.
на скорость выполнения жаловаться не приходилось - все работало мгновенно, но бенчмарков я не делал
вносить правки прямо в с++ код и видеть результат по F5 - это замечательно
описывать грамматику практически в терминах задания - великолепно
ну а скорость компиляции - спирит тут вне конкуренции, бесспорно, я не знаю ничего подобного - пришлось заодно решать задачу как снизить пиковые потребления памяти компилятором, потому что если на 8 гигах на десктопе оно ворочалось, то на 2 гигах на ноуте был сразу пиздец - студийный компилятор просто падал
ну а для реальной жизни - спирит не пригодился ни разу, вообще
D и Nemerle. Генератор парсеров на уровне библиотеки языка в обоих. Второй вон даже подчеркивает неправильные места со внятными всплывающими сообщениями о причинах ошибки даже ещё до компиляции и нет не читабельных ошибок в стиле кококо длинный список инстансов шаблона на страницу из нутрей буста кококо, разбирайся как хочешь).
вот что я хотел сказать
потом конечно пришлось вовсю пользоваться трюками, позволившими обойтись минутой и гигом оперативы в пике, но осадочек остался
Returns: Each function returns a string object holding the character representation of the value of its argument that would be generated by calling sprintf(buf, fmt, val) with a format specifier of "%d", "%u", "%ld", "%lu", "%lld", "%llu", "%f", "%f", or "%Lf", respectively, where buf designates an internal character buffer of sufficient size.
уверен, вендоры не парились и фразу would be поняли как should be
Но absolut наверное имел в виду "как указать другой формат, если не устраивает стандартный".
sprintf разве умеет в локали?
http://ideone.com/AVaSW
как сишную ru_RU перевести в крестоблядскую std::locale?
> what(): locale::facet::_S_create_c_locale name not valid
P.S. У меня в бубунте работает, на Ideone краш. Видимо нет у них русской локали.
Вот так (с пиндосским en_US):
http://ideone.com/pS8wQ
походу сишный компилятор и крестоблядский на разных физических машинах у них
ну будем честны, lexical_cast тоже по умолчанию использует глобальную локаль
http://liveworkspace.org/code/03f4d4b6e2921ecbced6c0e445d1ee25
(это если волшебный макрос не дефайнить)
тот же тест с std::to_string
Удобно ведь писать экстеншены? :)
Это я вернулся и тебя разбанил