【问题标题】:std::atoll with VC++标准::环礁与 VC++
【发布时间】:2011-07-07 12:25:16
【问题描述】:

我一直在使用来自cstdlibstd::atoll 使用gcc 将字符串转换为int64_t。该功能似乎在 Windows 工具链上不可用(使用 Visual Studio Express 2010)。最好的选择是什么?

我也有兴趣将strings 转换为uint64_t。取自 cstdint 的整数定义。

【问题讨论】:

标签: c++ int64 uint64 strtol


【解决方案1】:

MSVC有_atoi64等类似功能,见here

无符号64位类型见_strtoui64

【讨论】:

  • 对于其他人,作为参考,这似乎没有 uint64_t 的等价物,我转而使用 int64_t(从 3rd 方库中转换)
  • @Cookie,为无符号 64 位类型添加了类似函数的链接
【解决方案2】:
  • 使用字符串流 (<sstream>)

    std::string numStr = "12344444423223";
    std::istringstream iss(numStr);
    long long num;
    iss>>num;
    
  • 使用 boost lexical_cast (boost/lexical_cast.hpp)

     std::string numStr = "12344444423223";
     long long num = boost::lexical_cast<long long>(numStr);
    

【讨论】:

  • @Cookie:您进行了性能测试,发现将字符串转换为数字是您的瓶颈?
  • valgrind 告诉我,例如strtod 占总时间的 8%。 atol 以 4% 略落后。我实际上正在重写 strtod 以摆脱那些 8%。 stringstreams 比 atol 慢得多。 lexical_cast 是最慢的。大部分时间都花在解析大约 100 meg csv 上。
  • 如果绝对成本可以忽略不计,那么相对成本就不重要了。您的脚本运行时间是否足够长和/或经常足以证明优化的合理性? (学习目的当然可以)
  • 经常通宵运行,而且经常运行超过24小时,如果经常在所有8核上不间断运行,我经常要等待它。 20% 的性能差异非常明显。这真的是重点吗?接受我关心性能有那么难吗?或者你想在我得到答案之前剖析我的整个项目和方法吗?
  • 你不知道strtod()在VC++上是否有同样的性能?与 std::istringstream 相比,std::sscanf() 可能值得分析。
【解决方案3】:

如果您进行了性能测试并得出结论认为转换是您的瓶颈并且应该非常快地完成,并且没有现成的函数,我建议您自己编写。 这是一个运行速度非常快但没有错误检查并且只处理正数的示例。

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;
}

【讨论】:

【解决方案4】:

您的&lt;cstdlib&gt; 中是否有strtoull?是C99。而且 C++0x 还应该有 stoull 来直接处理字符串。

【讨论】:

  • 很遗憾,MSVC 不支持 C99。
【解决方案5】:

Visual Studio 2013 终于有了std::atoll

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2023-03-03
    • 2017-10-24
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-11-08
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多