我正在开发一个项目，该项目应该使用以下语法从命令行中调用：
program-name input-file
这个程序需要处理输入数据，计算一些东西并将结果输出到标准输出。
我选择使用C++语言，因为有很多原因我不想讨论。计算阶段将会高度符号化（类似于编译器），并且使用相当复杂的动态分配数据结构。特别是，它不适合RAII风格的编程。
我在想，如果我预计整个计算过程消耗的内存比可用内存少，并且操作系统在程序结束后可以一次性回收所有内存（假设程序在几秒钟内终止），那么是否可以不考虑释放内存？你们对此有什么感受?
作为备选方案，如果我的项目需要作为服务器或交互式运行，我想总是可以在源代码中加入垃圾收集器。有人使用过C++的垃圾收集器吗？它们工作得好吗？
在问题描述的特定情况下，它不应该会有任何问题。
然而，这并不完全正常。静态分析工具会对此提出抱怨。最重要的是，这会养成不好的习惯。
我感觉像是“卧槽!!!”
这么说吧：
你选择一种不包含垃圾回收器的编程语言，我们不能问为什么。
你基本上是在说你懒得去清理内存。
卧槽！懒惰并不是任何事情的好理由，尤其是在不释放内存的情况下玩弄内存。
释放内存吧，这是一种不好的习惯，场景可能会改变，到那时你可能有一百万个理由需要释放内存，而不这样做的唯一理由就是懒惰。不要养成坏习惯，要习惯做正确的事情，这样将来你就会更容易做对它们！！
不释放内存可能不会出现问题，但这是一种不好的做法。
Joel Coehoorn是正确的:
这不应该引起任何问题。
然而，这并不正常。 静态分析工具会抱怨 关于它。最重要的是，它建立了 不良习惯。
我还想补充一点，考虑在编写代码时思考释放内存可能比尝试事后修改更容易。所以我可能会使其释放内存;你不知道你的程序将来可能如何使用。
如果您想要一个真正简单的方法来释放内存，请查看Apache使用的“池”概念。
我认为这是不可接受的。您已经提到了潜在的未来问题。不要认为它们一定容易解决。
像“...鉴于我预计整个计算过程将消耗更少的时间...”这样的话，往往是致命的。同样，用某些功能重新调整代码是他们讨论但从未实现的事情之一。
短期内不释放内存可能听起来不错，但长期来看可能会带来巨大的问题负担。对我个人而言，我不认为这值得。
有两种策略。要么你从一开始就设计GC，这需要更多的工作，但会有回报。对于许多小对象，使用池分配器并跟踪内存池可能会更好。这样，您可以跟踪内存消耗，并避免许多类似的代码，但没有分配池可能会创建的问题。
要么您从一开始就在程序中使用智能指针。尽管它会使代码变得混乱，但我实际上更喜欢这种方法。一种解决方案是大量依赖模板，这可以减少引用类型时的冗余。
看看像WebKit这样的项目。他们的计算阶段类似于您的计算阶段，因为他们为HTML构建解析树。他们在整个程序中都使用智能指针。
最后：“这是一个风格问题...草率的工作往往会形成习惯。”- David Eddings的魔法城堡中的Silk。
像boost和TR1中的shared_ptr这样的引用计数智能指针也可以帮助您以简单的方式管理内存。
缺点是您必须包装使用这些对象的每个指针。