std::atoll с VC++

Я использовал std::atoll из cstdlib для преобразования строки в int64_t с помощью gcc. Эта функция недоступна в цепочке инструментов Windows (с использованием Visual Studio Express 2010). Какая лучшая альтернатива?

Я также заинтересован в преобразовании strings в uint64_t. Целочисленные определения взяты из cstdint.


person Cookie    schedule 07.07.2011    source источник
comment
кажется, эта проблема исправлена ​​в VS2013 connect.microsoft. com/VisualStudio/feedback/details/752386/   -  person Oleg Vazhnev    schedule 10.10.2013


Ответы (5)


MSVC имеет _atoi64 и аналогичные функции, см. здесь

Для 64-разрядных типов без знака см. _strtoui64

person nos    schedule 07.07.2011
comment
Для кого-то еще, в качестве справки, похоже, что у этого нет эквивалента для uint64_t, я переключился на работу с int64_t (извлекая его из сторонней библиотеки) - person Cookie; 07.07.2011
comment
@Cookie, добавлена ​​ссылка на аналогичные функции для беззнаковых 64-битных типов. - person nos; 08.07.2011

  • использовать строковые потоки (<sstream>)

    std::string numStr = "12344444423223";
    std::istringstream iss(numStr);
    long long num;
    iss>>num;
    
  • используйте буст lexical_cast (boost/lexical_cast.hpp)

     std::string numStr = "12344444423223";
     long long num = boost::lexical_cast<long long>(numStr);
    
person Armen Tsirunyan    schedule 07.07.2011
comment
@Cookie: вы провели тест производительности и обнаружили, что преобразование строки в число является вашим узким местом? - person Armen Tsirunyan; 07.07.2011
comment
valgrind говорит мне, что, например. strtod составляет 8% от общего времени. атол немного отстает с 4%. На самом деле я переписываю strtod, чтобы избавиться от этих 8%. stringstreams значительно медленнее, чем atol. а lexical_cast — самый медленный. Большая часть времени тратится на синтаксический анализ примерно 100 мегабайт csv. - person Cookie; 07.07.2011
comment
Относительные затраты не важны, если абсолютные затраты незначительны. Ваш скрипт работает долго и/или достаточно часто, чтобы оправдать оптимизацию? (для учебных целей, конечно, хорошо) - person Sebastian Mach; 07.07.2011
comment
Он часто работает ночью, а часто работает более 24 часов, если часто работает на всех 8 ядрах без остановок, и мне часто приходится его ждать. Разница в 20% в производительности очень заметна. Действительно ли здесь дело в этом? Неужели так трудно признать, что я забочусь о производительности? Или вы хотели бы проанализировать весь мой проект и подход, прежде чем я буду достоин ответа? - person Cookie; 07.07.2011
comment
Тогда вы не знаете, имеет ли strtod() такую ​​же производительность на VC++? std::sscanf() может стоить профилировать по сравнению с std::istringstream. - person Clifford; 07.07.2011

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

long long convert(const char* s)
{
    long long ret = 0;
    while(s != NULL)
    {
       ret*=10; //you can get perverted and write ret = (ret << 3) + (ret << 1) 
       ret += *s++ - '0';
    }
    return ret;
}
person Armen Tsirunyan    schedule 07.07.2011
comment
Спасибо, Армен, я мог бы. Это очень похоже на stackoverflow.com/questions/5830868/ для удвоения. - person Cookie; 07.07.2011

Есть ли в вашем <cstdlib> strtoull? Это С99. И C++0x также должен иметь stoull для работы непосредственно со строками.

person Kerrek SB    schedule 07.07.2011
comment
К сожалению, MSVC не поддерживает C99. - person nos; 07.07.2011

Visual Studio 2013 наконец-то имеет std::atoll.

person Paweł Bylica    schedule 25.09.2014