poYBAGK1IjOAJfBdAAFEbI8iulo184.png

C++++ 在嵌入式开发人员中发展缓慢。尽管许多工程师都很热情,但也有许多人非常务实,采取“如果没有坏,就不要修复”的方法并坚持使用 C。通常会担心一个特定的特性;通常该功能是异常处理。

poYBAGK1IjOAJfBdAAFEbI8iulo184.png

C++ 中的异常处理系统 (EHS) 与硬件中断意义上的异常完全无关。它旨在处理软件检测到的异常情况。目的是提供一种受控的故障模式,在这种模式下,需要从一些深度嵌套的函数调用中平滑退出(不求助于goto)。

EHS 的使用相当简单。在执行期间需要激活 EHS 的代码包含在try块中。throw语句用于断言异常,该异常由类标识。异常处理由catch块中的某些代码执行。对于可以断言的每种异常类型(即每个标识类),通常有一个catch块。

这看起来相当简洁和简单,并且确实提供了一种编写需要异常处理的可读代码的方法。但是,有一些关键点引起了嵌入式软件开发人员的合理关注:

如果您要使用 EHS,则必须为整个应用程序合并附加代码(编译器开关)。对于人类读者(或编译器)来说, try块中的代码可能直接或间接调用哪些函数并不明显。此附加代码会增加大小并降低执行性能。

许多编译器默认包含 EHS 代码。这意味着不知情的用户会自动合并开销,即使他们无意使用 EHS。编译器开关通常可用于激活或停用 EHS 代码生成。

如果您的应用程序的异常处理需求很简单,有两种方法可以部署 EHS 以减少开销:

使用通用catch块 [其中类型用“ 。.. ”指定],而不是为每种异常类型使用一个。

不要包含任何catch块。这会导致在抛出异常时调用库函数terminate() 。该功能可以自定义。

不使用 EHS 的理由很充分。然而,小心使用,它可能对许多设计都有好处。应尽早预计和仔细测量开销,以免在后期开发阶段造成问题。

Loading

发表回复