Вы можете специализировать lexical_cast для типов int и double . Используйте strtod и strtol в своих специализациях.

namespace boost {
template<>
inline int lexical_cast(const std::string& arg)
{
    char* stop;
    int res = strtol( arg.c_str(), &stop, 10 );
    if ( *stop != 0 ) throw_exception(bad_lexical_cast(typeid(int), typeid(std::string)));
    return res;
}
template<>
inline std::string lexical_cast(const int& arg)
{
    char buffer[65]; // large enough for arg < 2^200
    ltoa( arg, buffer, 10 );
    return std::string( buffer ); // RVO will take place here
}
}//namespace boost

int main(int argc, char* argv[])
{
    std::string str = "22"; // SOME STRING
    int int_str = boost::lexical_cast<int>( str );
    std::string str2 = boost::lexical_cast<std::string>( str_int );

    return 0;
}

Этот вариант будет быстрее, чем при использовании реализации по умолчанию, потому что в реализации по умолчанию существует построение тяжелых потоковых объектов. И это должно быть немного быстрее, чем printf , потому что printf должен анализировать строку формата.

lexical_cast является более общим, чем конкретный код, который вы используете в Java и Python. Неудивительно, что общий подход, который работает во многих сценариях (лексическое приведение - это не более чем потоковая передача, а затем обратно во временный поток и обратно), в конечном итоге оказывается медленнее, чем определенные процедуры.

(Кстати, вы можете получить лучшую производительность. вне Java, используя статическую версию, Integer.toString (int) . [1])

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

[1] Комментатор "stepancheg" усомнился в моем намеке на то, что статическая версия может дать лучшую производительность. Вот источник, который я использовал:

В текущем шаблоне утилиты SDK утечки нет. Как у вас создалось впечатление, что в шаблоне есть утечка? Это просто выделение памяти, которая необходима для представлений.

Утечка - это память, на которую нет указателей и которую больше нельзя освободить.

string s = Cast( i );

.

Однако, если производительность действительно важна для вас, вам следует рассмотреть возможность использования другого механизма. Вы можете написать свою собственную версию Cast (), которая (например) создает статический поток строк. Такая версия не будет потокобезопасной, но это может не иметь значения для ваших конкретных потребностей.

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

Как сказал Барри, lexical_cast является очень общим, вам следует использовать более конкретную альтернативу, например, проверьте itoa ( int- > строка ) и atoi ( строка -> int ).

если скорость важна, или вас просто интересует, насколько быстрыми могут быть такие преобразования с помощью C ++, есть интересующий поток по этому поводу.

Boost.Spirit 2.1 (который должен быть выпущен с Boost 1.40) кажется очень быстрым, даже быстрее, чем эквиваленты C (strtol (), atoi () и т. Д.).

К сожалению, у меня пока недостаточно репутации, чтобы прокомментировать ...

lexical_cast в первую очередь медленный, потому что он общий (поиск шаблонов происходит во время компиляции, поэтому вызовы виртуальных функций или другие поиски / разыменования не нужны). lexical_cast , на мой взгляд, медленный, потому что он основан на iostreams C ++, которые в основном предназначены для потоковых операций, а не отдельных преобразований, и потому что lexical_cast должен проверять и преобразовывать ошибки iostream сигналы. Таким образом:

• объект потока должен быть создан и уничтожен
• в случае строкового вывода выше, обратите внимание, что компиляторам C ++ трудно избежать копирования буфера (альтернативой является форматирование непосредственно в выходной буфер, например ] sprintf выполняет, хотя sprintf не может безопасно обрабатывать переполнение буфера)
• lexical_cast должен проверять ошибки stringstream ( ss.fail ( ) ), чтобы генерировать исключения при сбоях преобразования

lexical_cast - это хорошо, потому что исключения (IMO) позволяют отлавливать все ошибки без дополнительных усилий и потому, что у него есть унифицированный прототип. Я лично не понимаю, почему любое из этих свойств требует медленной работы (при отсутствии ошибок преобразования), хотя я не знаю таких быстрых функций C ++ (возможно, Spirit или boost :: xpressive?).

Редактировать: я только что нашел сообщение, в котором упоминается использование BOOST_LEXICAL_CAST_ASSUME_C_LOCALE для включения оптимизации «itoa»: http://old.nabble.com/lexical_cast-optimization-td20817583.html . Также есть ссылка на статью с немного более подробной информацией.