为什么 std:: setw 和 std::hex 不适合下面的代码?

Why std:: setw and std::hex not appropriate of code below?

本文关键字：std 代码 hex setw 为什么 不适合      更新时间：2023-10-16

我一直在看到某人的一些代码片段，如下所示：
在更改之前：

void pal::type3_message::debug_print(std::ostream & out) const
{
out << "### type3_message:" << 'n'
<< pal::as_hex_dump(as_bytes())
<< "lm_response = " << pal::as_hex_string(lm_response_)
<< "nnt_response = " << pal::as_hex_string(nt_response_)
<< "ndomain = " << domain_
<< "nuser = "   << user_
<< "nworkstation = " << workstation_
<< "nsession_key = " << pal::as_hex_string(session_key_)
<< std::hex << std::setw(8) << std::setfill('0')
<<"nssp_flags = " << ssp_flags_;
}

更改后：

std::string pal::type3_message::debug_print() const
{
std::ostringstream buf;
buf << "### type3_message:" << 'n'
<< pal::as_hex_dump(as_bytes())
<< "lm_response = " << pal::as_hex_string(lm_response_)
<< "nnt_response = " << pal::as_hex_string(nt_response_)
<< "ndomain = " << domain_
<< "nuser = "   << user_
<< "nworkstation = " << workstation_
<< "nsession_key = " << pal::as_hex_string(session_key_)
<< std::hex << std::setw(8) << std::setfill('0')
<<"nssp_flags = " << ssp_flags_;
return buf.str();
}

我不太确定上面的变化，有谁能告诉我这应该如何发生以及它的深刻意义？ 期待回应和欣赏。

我不确定你在问什么，所以我只是解释代码示例的作用以及两个函数之间的主要区别是什么：

void pal::type3_message::debug_print(std::ostream & out) const

此函数将消息写入out参数引用的输出流。它没有返回值。

std::string pal::type3_message::debug_print() const

此函数似乎输出相同的消息，但不是将其写入流，而是将消息存储在字符串中。此字符串由函数返回。

这两个函数的实现看起来非常相似，因为第二个函数在内部使用临时std::ostringstream。这是仅存在于内存中的流。相反，您可以将像std::ofstream这样的文件流传递给第一个函数。

如果您想了解更多信息，请澄清您的问题。

可以告诉我这应该如何发生以及它的深刻意义吗？

第一种方法接收一个std：：ostream&参数，并将10多个不同的文本块流式传输到其中。

第二种方法是将相同的 10 个文本块流式传输到本地创建的(自动变量(std：：ostringstream 中。 这会在返回字符串之前连接块。

可能的使用示例(在 std：：cout 上实现相同的输出(：

pal::type3_message::debug_print(std::cout);
std::cout << std::endl;

和

std::cout << pal::type3_message::debug_print() << std::endl;

我更喜欢 std：：stringstream 方法，但我同时使用了这两种方法。

在第一种方法中，线程可以在更多位置(10 个之间("中断"，这可能会对非私有流工作产生影响。这会导致问题吗？ 我没有在桌面上调查。

第二种方法完成串联，然后返回一个字符串。 所有以前的中断点仍然存在，但不会影响到共享流目标 std：：cout 的交付。 请注意，此路径中仍有 1(或 2(个中断位置(用于附加字符串(。 不过，这可能不太可能产生可见的问题。

在我曾经使用的嵌入式系统中，由于它有驱动程序，第二种方法显然更好(就使用过程中的线程中断而言(，并且似乎不需要输出通道上的互斥防护。

在 Ubuntu 上，我添加了互斥守卫来访问 std：：cout ...以避免"混合"文本，尽管我没有确认这篇文章中描述的更改可能已经足够。

我有一个带有轮询缓冲区的 ram-log，并且该共享资源具有互斥防护。 多个线程对同一日志的贡献永远不会有任何问题。

注意：根据帖子问题，我认为在 std：：hex 或 std：：setw 方面的任何流努力都没有区别，两者都使用相同。

7月2日更新，评论

我同意"之后"是我更喜欢的。

我不认识"不要弄乱借来的东西"这句话。我看了看，决定谷歌关于这个短语的报告与软件无关。

但它让我想起了我听到的一个可能相关的警告，"代码就像洋葱"。那个对我重复这个(痴迷地(的人拒绝"修复"东西(例如崩溃(，因为，我推测，他担心任何变化都可能以无法察觉的方式破坏"行为"。因此，他处理了"所有的洋葱层"，直到他确定不会发生任何不好的事情，然后他才提交代码更改。"分析瘫痪"浮现在脑海中。

显然，我对尝试其他事情更加宽容(并测试，测试，测试......那次崩溃很容易修复，而且崩溃肯定阻碍了了解洋葱深层的进展。

相关文章：