我正在编写嵌入式应用。在某些地方,我经常使用std :: ostringstream,因为它对我来说非常方便。但是,我刚刚发现性能受到了极大的影响,因为向流中添加数据会导致大量调用malloc和free。有什么方法可以避免吗?
我的第一个想法是使ostringstream静态并使用ostringstream :: set(“”)重置它。但是,由于我需要函数可重入,所以无法完成。
答案 0 :(得分:2)
如果您知道在创建流之前数据有多大,您可以使用ostrstream,其构造函数可以将缓冲区作为参数。因此,将不会对数据进行内存管理。
答案 1 :(得分:2)
批准处理此问题的方法可能是创建您自己的basic_stringbuf
对象以与ostringstream
一起使用。为此,您有几个选择。一种是使用固定大小的缓冲区,如果你尝试创建太长的输出,则overflow
只会失败。另一种可能性是使用向量作为缓冲区。与std :: string不同,vector保证附加数据具有分摊的常量复杂性。它也永远不会从缓冲区释放数据,除非你强制它,所以它通常会增长到你正在处理的最大尺寸。从那时起,它不应该分配或释放内存,除非你创建一个超出当前可用长度的字符串。
答案 2 :(得分:2)
好吧,Booger的解决方法是切换到sprintf()
。它不安全且容易出错,但通常更快。
并非总是如此。我们不能在初始化后的实时作业中使用它(或ostringstream),因为它们都执行内存分配和解除分配。
我们解决这个问题的方法是跳过很多箍,以确保我们在启动时执行所有字符串转换(当我们不必实时)时。我认为有一种情况我们将自己的转换器写入固定大小的堆栈分配数组。对于有问题的特定转化,我们可以依靠大小限制。
对于更通用的解决方案,您可以考虑编写自己的ostringstream版本,该版本使用固定大小的缓冲区(当然,对边界内的边界进行错误检查)。这将是一项工作,但如果你有这些流操作的很多,它可能是值得的。
答案 3 :(得分:1)
std::ostringsteam
是一个便利界面。它通过提供自定义std::string
将std::ostream
与std::streambuf
相关联。您可以实现自己的std :: streambuf。这允许您进行整个内存管理。您仍然可以获得std::ostream
的良好格式,但您可以完全控制内存管理。当然,结果是你将格式化的输出放在char[]
中 - 但如果你是嵌入式开发人员,这可能不是什么大问题。