关于UB的问题

方兆国

回复 20# starwing83

额，就是要过滤错误输入的意思呗
   

starwing83

回复 21# 方兆国


    只要文档里面写出即可，犯不着过滤。

只是说明一个编程的理念罢了，先划清范围再慢慢蚕食，而不是一上来就咋地咋地。

方兆国

回复 22# starwing83


    这样啊，我还以为多复杂呢，谢谢你~\(≧▽≦)/~

_Rayx

UB就是说：
标准 委员会也不知道到底结果是什么，因为他们是标准委员会，而不是编译器，编译器想怎么实现就怎么实现，当然一般如果实现起来还是有点靠谱的想法的，但这样就会造成一个问题，你的代码给别人玩的时侯就会出现问题，别人可不会管你什么UB，只会认为你的代码有问题。

所以，如果只是自己偷偷玩，且知道编译器是怎么处理的，你完全可以使用UB，但是像做工程，或者开源一个玩意，最好避免他，当然你能确定所有的编译器都同样处理这个UB另说，但你不能保证最新的编译器会以同样的方式来处理它。

方兆国

回复 24# _Rayx


    额，就是像楼上所说的那样，对可能出错的地方都进行判断，是不是这个意思啊
    话说判断太多，程序的效率会下降

gvim

1. C_standard {
   
2.     abstract impl_operations;
   
3.    
   
4.     standard_operations{};
   
5. }
   
6. Gcc :: C_standard {
   
7.     impl_operations {};
   
8.     other_operations_gcc{};
   
9. }
   
10. LLVM::C_standard {
    
11.     impl_operations {};
    
12.     other_operations_llvm{};
    
13. }
    

复制代码

standard_operations是标准明确定义的行为。
abstract impl_operations是标准未明确定义的行为，或者提出几种选择，该行为是编译器实现相关，怎么实现都认为是正确的，并且符合标准。
other_operations_xxx是标准未明确定义的行为，该行为可以是编译器根据自己的设计予以实现，也可以是编译器报异常报错误，也可以是运行期异常，怎么实现都认为是非正确的。虽然other_operations_xxx可以有计算结果，虽然这种计算遵循最小惊讶原则，只是通常这样的结果被认为是编译器对新手的照顾。用C的最大难点是：你需要明白你在做什么，并且需要知道怎么做，除此之外还需要知道谁在做。
上门伪代码中子类实现的东西通常不具备移植性。

方兆国

回复 26# gvim


    恩，我也看到了，就是说要做可移植的代码，就不能有UB，或者说代码里有的话，使用手册里有说明就可以了，不考虑可移植，就可以有，是不

gvim

回复 27# 方兆国

不光是移植问题，运行期的不确定性也会导致问题。
所以解决办法是1：避免不确定，比如a+=a-=a*a，2：缩小范围把不确定变成确定，比如assert（），3：如果必须存在不确定的东西，在文档里红色注明可能产生的条件和可能的影响，在系统层面配合不触发某些条件。（或许碰到这点更应该改的是你的设计了）

snow888

_Rayx

回复 25# 方兆国


    尽量避免使用UB，因为很多时候会造成一些难找察觉的bug.