如何在C++类的成员初始化列表中调用函数?——适配libjpeg-turbo的RAII包装类构造函数改造
解决libjpeg-turbo RAII包装类的-Weffc++编译警告问题
首先,我完全理解你的需求——保持srcinfo的栈存储、维持RAII逻辑,同时通过-Weffc++的编译检查。这个警告的根源是-Weffc++要求所有非静态成员变量必须在成员初始化列表中显式初始化,而你的原构造函数是在函数体里直接操作srcinfo,没有先在初始化列表中处理它。
问题分析
jpeg_decompress_struct是C风格的结构体,没有自定义构造函数。在C++中,如果不在初始化列表中显式初始化这类成员,编译器会对其进行默认初始化(栈上的话就是未初始化,成员值是随机的),这不仅触发-Weffc++警告,还可能给jpeg_create_decompress带来潜在风险——虽然libjpeg的初始化函数通常会覆盖所有必要字段,但显式初始化总归更安全。
修改方案
我们只需要在构造函数的初始化列表中对srcinfo进行值初始化(用srcinfo()),然后再调用jpeg_create_decompress即可。这样既满足了编译器的警告要求,又给libjpeg提供了一个干净的结构体实例:
class Decompress { typedef jpeg_decompress_struct *ptr; jpeg_decompress_struct srcinfo; public: // 成员初始化列表中值初始化srcinfo,再执行库初始化函数 Decompress() : srcinfo() { jpeg_create_decompress(&srcinfo); } ~Decompress() { jpeg_destroy_decompress(&srcinfo); } operator ptr() { return &srcinfo; } jpeg_decompress_struct *operator->() { return &srcinfo; } };
为什么这样可行?
srcinfo()会对这个C结构体进行零初始化,所有成员被置为0/null,这完全符合libjpeg-turbo对输入结构体的预期;- 初始化列表的操作先于构造函数体执行,
jpeg_create_decompress拿到的是一个已初始化的结构体指针,逻辑上和原代码一致,但更规范; - 完美规避了
-Weffc++的警告,同时保持了srcinfo的栈存储和RAII的核心逻辑——构造时创建解压上下文,析构时销毁。
内容的提问来源于stack exchange,提问作者malat
相关产品推荐
相关产品推荐

