“正确的 C++ 解决方案”——使用 C++ 时，c 风格的逻辑是否“不好”？

Question

所以最近我开始讨论如何解决一个问题，具体问题是：我如何找到 1 到 100 万之间的所有回文。我说，“用atoi做一个字符串，用for循环反转字符串，用strcmp比较有问题的字符串。

几分钟后，有人问“为什么要在 C++ 中使用 C 风格的解决方案”。我发现自己对使用直接且易于理解的代码解决这个问题的简单、更“C++”的方法感到困惑。有人愿意在这个上照亮我吗？

编辑：itoa 不是 atoi

Answer 1

很简单，C++ 流保证是内存安全和异常安全的，失败不同于任何返回值，C++ 字符串是内存安全和异常安全的。 C-strings 和atoi 在人类已知的几乎所有方面都非常不安全。以这种方式编写的代码更容易出错。

Answer 2

示例 C++ 解决方案：

#include <algorithm>
#include <iterator>
#include <iostream>
#include <boost/iterator/counting_iterator.hpp>
#include <boost/lexical_cast.hpp>

namespace {
   bool is_palindrome(unsigned int i) {
     const std::string& s = boost::lexical_cast<std::string>(i);
     return std::equal(s.begin(), s.end(), s.rbegin());
   }

   const unsigned int stop = 1000000;
}

int main() {
   std::remove_copy_if(boost::counting_iterator<unsigned int>(1),
                       boost::counting_iterator<unsigned int>(stop),
                       std::ostream_iterator<unsigned int>(std::cout, "\n"),
                       std::not1(std::ptr_fun(is_palindrome)));
}

（我用std::remove_copy_if来弥补C++0x中std::copy_if的不足）

为了完整起见，我实现了一个生成回文的版本，而不是针对谓词测试候选者：

#include <boost/lexical_cast.hpp>
#include <boost/iterator/counting_iterator.hpp>
#include <boost/iterator/transform_iterator.hpp>
#include <algorithm>
#include <iterator>
#include <iostream>
#include <cassert>

namespace {
  template <int ver>
  unsigned int make_palindrome(unsigned int i) {
     std::string s = boost::lexical_cast<std::string>(i);
     assert(s.size());
     s.reserve(s.size()*2);
     std::reverse_copy(s.begin(), s.end()-ver, std::back_inserter(s));
     return boost::lexical_cast<unsigned int>(s);
  }
}

int main() {
   typedef boost::counting_iterator<unsigned int> counter;
   std::merge(boost::make_transform_iterator(counter(1), make_palindrome<1>),
              boost::make_transform_iterator(counter(999), make_palindrome<1>),
              boost::make_transform_iterator(counter(1), make_palindrome<0>),
              boost::make_transform_iterator(counter(999), make_palindrome<0>),
              std::ostream_iterator<unsigned int>(std::cout, "\n"));
}

（我认为我可以使用 boost.range 而不是 std::merge）

我想讨论的重点是“这是一种更好的*方式来编写它吗？”。我喜欢以这种风格编写诸如回文之类的问题的一点是，您会得到“如果它编译它可能是正确的”启发式。即使存在错误，它仍然会在运行时得到合理处理（例如来自lexical_cast 的异常）。

这是一种与 C 编程明显不同的思维方式（但在某些方面与 Haskell 奇怪地相似）。它带来了许多额外安全方面的好处，但编译器错误消息可能很糟糕，并且很难改变您对问题的看法。

归根结底，重要的是“工作量越少，错误越少？”。如果没有一些指标提供帮助，我无法回答这个问题。

*对于更好的一些定义。

Answer 3

与您的解决方案等效的 C++ 是：

1. 使用 stringstream 将数字转换为 std::string。
2. 使用std::reverse_copy 反转字符串。
3. 使用 == 比较字符串。

1 比使用itoa（您可能是这个意思）要好，因为您不必自己为创建的字符串分配内存，也不会出现缓冲区溢出。

2 更好，因为您不必再​​担心为反转字符串分配内存，也不会复制现有功能。

3 更好，因为string1 == string2 比使用 strcmp 读取更好。

Answer 4

atoi 使得无法检测输入错误。而stringstream 可以完成相同的工作，并且可以轻松检测到错误。

Answer 5

我认为一个更合适的问题是为什么不应该在 C++ 中使用基于 C 的解决方案？如果它比“纯”C++ 解决方案更简单、更易读，我知道我会选择 C ​​风格的解决方案。鉴于您想出的解决方案既聪明又简单，相应的 C++ 解决方案可能有点矫枉过正，而且考虑到问题的简单性，我不确定 C++ 可以为解决方案带来什么建议。