在标准化之前的C早期，实现有各种方法来处理各种操作的exception和半exception情况。 如果没有先配置，其中一些会触发可能导致随机代码执行的陷阱。 因为此类陷阱的行为超出了C标准的范围（并且在某些情况下可能由运行程序控制之外的操作系统控制），并且避免要求编译器不允许依赖此类陷阱的代码陷阱继续这样做，可能导致此类陷阱的操作行为完全取决于编译器/平台的判断。
到20世纪90年代末，虽然C标准没有要求这样做，但每个主流编译器都采用了许多这种情况的共同行为; 使用这样的行为将允许在代码速度，大小和可读性方面进行改进。
由于不再支持请求以下操作的“明显”方式，因此在使用较旧的编译器时，应如何以不妨碍可读性的方式替换它们，也不会对代码生成产生负面影响？ 出于描述的目的，假设int是32位， ui是unsigned int， si是signed int， b是unsigned char。
“超现代”编译器是否为上述提供了任何良好的替代品，这些替代品不会降低代码大小，速度或可读性中的至少一个，同时不提供其他任何改进？ 据我所知，不仅99％的编译器在整个20世纪90年代都可以完成上述所有工作，但是对于每个例子，人们都可以在几乎所有这些编码器上以相同的方式编写代码。 一些编译器可能试图用无人看守的跳转表来优化左移和右移，但这是我能想到的唯一一种情况，即20世纪90年代20世纪90年代平台的编译器对“明显”的编码方式有任何问题以上任何一种。 如果那些超现代的编译器已不再支持经典forms，那么它们作为替代品提供了什么？
现代标准C以这样的方式指定：当且仅当您编写代码时才能保证它是可移植的，而不会对它将运行的底层硬件有更多的期望，而不是C抽象机器给出的隐式和明确标准描述。
您仍然可以编写针对给定目标CPU和体系结构在给定优化级别具有特定行为的特定编译器，但是不要期望任何其他编译器（现代或其他编译器，或者甚至是您编写的那个的小修订版）如果您的代码违反了标准规定期望任何明确定义的实现不可知行为是不合理的条件，那么请尽量试图直观地追求您的期望。
两个一般原则适用于标准C和标准C ++：
根据这些原则，您通常可以获得一种定义明确的方法来实现相同的结果，然后将信任 – validation原则应用于生成的代码的质量。 例如，使用明确定义的行为制作移位函数，并让优化器删除架构本身保证的任何不需要的检查。
// Performs 2 for unsigned numbers. Also works for signed // numbers due to rule for casting between signed and unsigned // integer types. inline uint32_t lsl32(uint32_t ui, unsigned int b) { if (b >= 32) return 0; return ui << b; } // Performs 3 for unsigned numbers. inline uint32_t lsr32(uint32_t ui, unsigned int b) { if (b >= 32) return 0; return ui >> b; } // Performs 3 for signed numbers. inline int32_t asr32(int32_t si, unsigned int b) { if (si >= 0) return lsr32(si, b); if (b >= 31) return -1; return ~(~(uint32)si >> b); }
对于4和5，转换为无符号，进行数学运算，然后转回签名。 这会产生非陷阱明确定义的行为。
以上就是c/c++开发分享对于以前广泛支持的行为，有哪些替代品可用于C标准未定义的行为相关内容,想了解更多C/C++开发(异常处理)及C/C++游戏开发关注计算机技术网(www.ctvol.com)!)。
本文来自网络收集，不代表计算机技术网立场，如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址：https://www.ctvol.com/c-cdevelopment/549346.html