“IB”到底做什么？和“UB”意思是？
我见过多次使用术语“IB”和“UB”，特别是在 C++ 上下文中。我试过用谷歌搜索它们，但显然这些两个字母的组合有很多用途。 ：P
所以，我问你......当他们说得好像他们是一件坏事时，他们是什么意思？
I've seen the terms "IB" and "UB" used several times, particularly in the context of C++. I've tried googling them, but apparently those two-letter combinations see a lot of use. :P
So, I ask you...what do they mean, when they're said as if they're a bad thing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
IB：实现定义的行为。该标准将其留给特定的编译器/平台来定义精确的行为，但要求对其进行定义。
使用实现定义的行为可能很有用，但会降低代码的可移植性。
UB：未定义行为。该标准未指定调用未定义行为的程序应如何表现。又称“鼻妖”，因为理论上它可以让恶魔从鼻子里飞出来。
使用未定义的行为几乎总是一个坏主意。即使有时看起来可行，但对环境、编译器或平台的任何更改都可能会随机破坏您的代码。
IB: Implementation-defined Behaviour. The standard leaves it up to the particular compiler/platform to define the precise behaviour, but requires that it be defined.
Using implementation-defined behaviour can be useful, but makes your code less portable.
UB: Undefined Behaviour. The standard does not specify how a program invoking undefined behaviour should behave. Also known as "nasal demons" because theoretically it could make demons fly out of your nose.
Using undefined behaviour is nearly always a bad idea. Even if it seems to work sometimes, any change to environment, compiler or platform can randomly break your code.
实现定义的行为和未定义的行为
C++ 标准对于各种构造的影响非常具体，特别是您应该始终注意这些类别的问题：
未定义的行为意味着存在绝对不给予任何保证。该代码可能会起作用，也可能会点燃你的硬盘，或者让恶魔飞出你的电脑。鼻子。就 C++ 语言而言，绝对任何事情都可能发生。实际上，这通常意味着您有一个不可恢复的错误。如果发生这种情况，您就不能真正信任您的应用程序的任何（因为这种未定义行为的影响之一可能就是弄乱应用程序其余部分使用的内存）。它不需要一致，因此运行该程序两次可能会产生不同的结果。它可能取决于月相、您所穿衬衫的颜色或绝对其他任何因素。
未指定的行为意味着程序必须做一些理智且一致的事情，但不需要记录这一点。
实现定义的行为与未指定的行为类似，但也必须由编译器编写者记录。一个例子是
reinterpret_cast的结果。 通常，它只是更改指针的类型，而不修改地址，但映射实际上是实现定义的，因此编译器可以映射到完全不同的地址，只要它记录了这个选择。另一个例子是 int 的大小。 C++ 标准不关心它是 2、4 还是 8 字节，但必须由编译器记录但所有这些的共同点是最好避免它们。如果可能，请坚持 C++ 标准本身 100% 指定的行为。这样，您就可以保证可移植性。
您通常还必须依赖一些实现定义的行为。这可能是不可避免的，但您仍然应该注意它，并意识到您所依赖的东西可能会在不同编译器之间发生变化。
另一方面，应始终避免未定义的行为。一般来说，您应该假设它会使您的程序以某种方式爆炸。
Implementation-defined behavior and Undefined behavior
The C++ standard is very specific about the effects of various constructs, and in particular you should always be aware of these categories of trouble:
Undefined behavior means that there are absolutely no guarantees given. The code could work, or it could set fire to your harddrive or make demons fly out your nose. As far as the C++ language is concerned, absolutely anything might happen. In practical terms, this generally means that you have an unrecoverable bug. If this happens, you can't really trust anything about your application (because one of the effects of this undefined behavior might just have been to mess up the memory used by the rest of your app). It's not required to be consistent, so running the program twice might give different results. It may depend on the phases of the moon, the color of the shirt you're wearing, or absolutely anything else.
Unspecified behavior means that the program must do something sane and consistent, but it is not required to document this.
Implementation-defined behavior is similar to unspecified, but must also be documented by the compiler writers. An example of this is the result of a
reinterpret_cast. usually, it simply changes the type of a pointer, without modifying the address, but the mapping is actually implementation-defined, so a compiler could map to a completely different address, as long as it documented this choice. Another example is the size of an int. The C++ standard doesn't care if it is 2, 4 or 8 bytes, but it must be documented by the compilerBut common for all of these is that they're best avoided. When possible, stick with behavior that is 100% specified by the C++ standard itself. That way, you're guaranteed portability.
You often have to rely on some implementation-defined behavior as well. It may be unavoidable, but you should still pay attention to it, and be aware that you're relying on something that may change between different compilers.
Undefined behavior, on the other hand, should always be avoided. In general, you should just assume that it makes your program explode in one way or another.
IB：是实现定义的行为 - 编译器必须记录它的作用。对负值执行
>>操作就是一个示例。UB：未定义的行为 - 编译器可以做任何事情，包括简单地崩溃或给出不可预测的结果。取消引用空指针属于这一类，但也包括一些更微妙的事情，例如超出数组对象范围的指针算术。
另一个相关术语是“未指定的行为”。这是介于实现定义和未定义行为之间的情况。对于未指定的行为，编译器必须根据标准执行某些操作，但标准给出的具体选择取决于编译器，不需要定义（甚至不需要一致）。像子表达式的求值顺序之类的事情就属于这一类。编译器可以按照它喜欢的任何顺序执行这些操作，并且可以在不同的构建中甚至在同一构建的不同运行中以不同的方式执行这些操作（不太可能，但允许）。
IB: is implementation defined behavior - the compiler must document what it does. Performing a
>>operation on a negative value is an example.UB: undefined behavior - the compiler can do what ever, including simply crashing or giving unpredictable results. Dereferencing a null pointer falls into this category, but also subtler things like pointer arithmetic that falls outside the bounds of an array object.
Another related term is 'unspecified behavior'. This is kind of between implementation defined and undefined behaviors. for unspecified behavior, the compiler must do something according to the standard, but exactly which choices the standard gives it is up to the compiler and need not be defined (or even consistent). Things like order of evaluation of sub-expressions falls in this category. The compiler can perform these in whatever order it likes, and could do it differently in different builds or even in different runs of the same build (unlikely, but permitted).
简短版本：
实现定义的行为 (IB)： 正确编程但不确定*
未定义的行为 (UB)： 编程不正确（即 bug !)
*) 就语言标准而言是“不确定的”，它当然在任何固定平台上都是确定的。
The short version:
Implementation-defined behaviour (IB): Correctly programmed but indeterminate*
Undefined behaviour (UB): Incorrectly programmed (i.e. a bug!)
*) "indeterminate" as far as the language standard is concerned, it will of course be determinate on any fixed platform.
UB：未定义行为
IB：实现定义的行为
UB: Undefined Behavior
IB: Implementation-defined Behavior