Question

所以我之前看过这样说过，以这种方式使用工会是一个坏主意。我知道这是技术上未定义的行为。但是，如果我使用的是C ++ 11（因此仅使用全新的编译器），那么诚实地以下代码真的有多糟糕？这真的很可能会炸毁我吗？可以改善吗？

Uncaught TypeError: $(...).sortable is not a function
    at HTMLDocument.<anonymous> (post.php?post=37529836268790&action=edit:1512)
    at i (jquery.js?ver=1.12.4:2)
    at Object.fireWith [as resolveWith] (jquery.js?ver=1.12.4:2)
    at Function.ready (jquery.js?ver=1.12.4:2)
    at HTMLDocument.K (jquery.js?ver=1.12.4:2)

就像我说的，我知道这是C ++中的UB，因此没有理由指出这一点。我的问题是在这种情况下，这真的很重要吗？

Answer 1

如果我正确理解这仅适用于仿真器，那么实际上您不需要8位和16位值来占用相同的存储，您只是想对同一数据进行不同的访问。

我的建议是将寄存器封装在一个类中（例如，一个register_t类，它存储单个16/32/64值，然后您也可以将其作为8/16/32位访问）。根据您的需要，您甚至可能返回一个代理对象作为一种引用，使您可以分配部分寄存器（例如，能够执行reg.l() += 1）。

一个简单的示例可能看起来像这样：16 bit register_t with proxy reference to constituent bytes（其他运算符，位宽度和const的正确性作为练习供读者阅读）。以这种方式（除了不是UB）这样做的另一个优点是，您无需关心字节顺序。

如果您也想为寄存器使用正确的名称，则可以将许多这些寄存器封装在另一个类中，以通过适当命名的成员函数提供对命名寄存器的访问。

Answer 2

如果您写入工会的成员，然后访问与工会的其他成员相同的数据，则行为是不确定的，除非类型之一是char类型。

所以这段代码似乎很好。如果您使用32位寄存器尝试了相同的操作（如果您尝试模拟x86寄存器，那将是不正确的，但这不是问题），那么写入16位元素并读回为32位元素将是未定义的行为。

顺便说一句。 memcpy，memset和memmove以字节为单位访问数据。正式。

使用联合在仿真器中模拟CPU寄存器是否合适？

2 个答案: