10

I have been using std::atoll from cstdlib to convert a string to an int64_t with gcc. That function does not seem to be available on the Windows toolchain (using Visual Studio Express 2010). What is the best alternative?

I am also interested in converting strings to uint64_t. Integer definitions taken from cstdint.

Sai Kalyan Kumar Akshinthala
  • 11,704
  • 8
  • 43
  • 67
Cookie
  • 12,004
  • 13
  • 54
  • 83
  • it seems this problem is fixed in VS2013 http://connect.microsoft.com/VisualStudio/feedback/details/752386/std-atoll-not-found – Oleg Vazhnev Oct 10 '13 at 10:41

5 Answers5

8

MSVC have _atoi64 and similar functions, see here

For unsigned 64 bit types, see _strtoui64

nos
  • 223,662
  • 58
  • 417
  • 506
  • For anyone else, as a reference, this doesn't seem to have an equivalent for uint64_t, I switched to working with int64_t (casting it from a 3rd party library) – Cookie Jul 07 '11 at 16:35
  • @Cookie, added link to similar functions for unsigned 64 bit types – nos Jul 08 '11 at 19:04
5

  • use stringstreams (<sstream>)

    std::string numStr = "12344444423223";
std::istringstream iss(numStr);
long long num;
iss>>num;

  • use boost lexical_cast (boost/lexical_cast.hpp)

     std::string numStr = "12344444423223";
 long long num = boost::lexical_cast<long long>(numStr);
Armen Tsirunyan
  • 130,161
  • 59
  • 324
  • 434
  • 5
    @Cookie: You have run a performance test and found that converting a string to a number is your bottleneck? – Armen Tsirunyan Jul 07 '11 at 12:32
  • valgrind is telling me that e.g. strtod is 8% of total time. atol is a bit behind with 4%. I am actually rewriting strtod to get rid of those 8%. stringstreams are considerably slower than atol. and lexical_cast is the slowest. Most of the time is spent parsing some 100 meg csv. – Cookie Jul 07 '11 at 12:35
  • The relative costs are not important if the absolute costs are negligible. Does your script run long and/or often enough to justify optimizations? (for learning purposes is of course okay) – Sebastian Mach Jul 07 '11 at 12:41
  • 3
    It runs often overnight, and it often runs over 24 hours, if often runs on all 8 cores non-stop, and I often have to wait for it. A 20% difference in performance is very noticeable. Is this really the point here? Is it that hard to accept that I care about performance? Or would you like to dissect my whole project and approach before I am worthy of an answer? – Cookie Jul 07 '11 at 12:56
  • You do not know then whether strtod() has the same performance on VC++? `std::sscanf()` might be worth profiling in comparison to std::istringstream. – Clifford Jul 07 '11 at 13:08
2

If you have run a performance test and concluded that the conversion is your bottleneck and should be done really fast, and there's no ready function, I suggest you write your own. here's a sample that works really fast but has no error checking and deals with only positive numbers.

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;
}
Armen Tsirunyan
  • 130,161
  • 59
  • 324
  • 434
  • Thanks Armen, I just might. It is very similar to http://stackoverflow.com/questions/5830868/c-stringstream-is-too-slow-how-to-speed-up for doubles. – Cookie Jul 07 '11 at 13:10
1

Visual Studio 2013 finally has std::atoll.

Paweł Bylica
  • 3,780
  • 1
  • 31
  • 44
1

Do you have strtoull available in your <cstdlib>? It's C99. And C++0x should also have stoull to work directly on strings.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084