我正在使用
a small piece of code生成PDF文件,这是我在互联网上找到的,并尝试(轻柔地)优化它,因为创建文件需要很长时间.在分析之后,我将其缩小到以下代码：
std::ostringstream tmp;
tmp << std::hex << std::uppercase << std::setfill('0') <<
std::setw(2) << r << " " <<
std::setw(2) << g << " " <<
std::setw(2) << b;
out << tmp.str();
发现是一个紧密的循环,没有一个ostringstream,它基本上包含了整个PDF内容,然后才写入文件.我发现tmp.str()是在该循环中花费最多时间的行,并且在查找C引用时看到str()将返回流的底层字符串的副本.
然后,我想删除该副本并直接使用会更快.所以我抛弃了tmp并直接做了：
out << std::hex << std::uppercase << std::setfill('0') <<
std::setw(2) << r << " " <<
std::setw(2) << g << " " <<
std::setw(2) << b;
但现在,生成的PDF文件被视为“已损坏”,无法通过PDF阅读器打开,而前一个可能是.我使用两种方法创建了一个PDF(使用tmp流和没有)来比较行输出,但没有发现明显的差异……
那么,这可能是什么原因呢？是否有理由使用该临时流？是的,为什么它可能与直接使用out stream不同？
我认为它可能与换行或操纵器有关,但在这些上找不到任何重要的东西
解决方法
要考虑的是io操纵器(例如std :: hex)从流上的那一点开始是持久的.
因此,一旦插入std :: hex操纵器,从此时开始,所有积分值都以十六进制格式打印出来.
由于操纵器处于瞬态流,因此您之前的方法没有出现此问题.一旦完成,你可以尝试插入std :: dec操纵器……
从Jan Hudec的评论中拉出来,Boost IO State Savers是清楚地处理这个问题的好方法.
