一些问题：vs相关、dll相关、编译相关-Aet

Bingliaolong 2025-10-27 10:51 Aet | 隐藏边栏 | 抢沙发 | 1 0

文章评分 1 次，平均分 5.0 ：

编译相关

`#pragma init_seg`

概述
1. 是微软C++编译器中的一个编译指令，专门用于精细控制全局静态对象（包括静态变量）的构造和析构顺序
2. 在解决复杂的初始化依赖或DLL加载问题时非常有用
语法

#pragma init_seg( { compiler | lib | user | "section-name" [, func-name] } )

#pragma init_seg("user_defined")

优先级
1. compiler
  最高优先级
  此组别的对象最先构造，最后析构
  通常保留给C/C++运行时库本身使用（如 cin, cout的初始化）
2. lib
  中等优先级
  此组别的对象在 compiler组之后构造，在 user组之前析构。适用于第三方类库供应商
3. user
  默认及最低优先级
  大多数用户代码默认属于此组。此组别的对象最后构造，最先析构
4. section-name
  如user_defined，特殊模式
  此组别的对象不会自动初始化
  它允许你显式指定一个自定义的段（节）名称，编译器只会将所需对象的构造函数指针放置在该命名的段中，而不会自动调用它们
  你的代码必须手动遍历该段并调用每个构造函数来完成初始化
示例

#include <stdio.h>

// 1. 定义一个函数指针类型，用于指向构造函数/析构函数

typedef void (__cdecl *PF)(void);

// 2. 定义两个标记，用来确定自定义段的起始和结束边界

// 编译器会将位于这两个标记之间的函数指针视为需要手动初始化的对象

#pragma section(".my_initializer$a", read)

__declspec(allocate(".my_initializer$a")) const PF InitSegStart = (PF)1;

#pragma section(".my_initializer$z", read)

__declspec(allocate(".my_initializer$z")) const PF InitSegEnd = (PF)1;

// 3. 声明手动初始化函数

void InitializeMyObjects() {

const PF *x = &InitSegStart;

// 遍历段中的所有函数指针并调用

for (++x; x < &InitSegEnd; ++x) {

if (*x) {

(*x)(); // 调用构造函数

}

// 4. 使用自定义段，并声明一个全局对象

#pragma init_seg(".my_initializer$m") // 注意段名格式

class MyCriticalClass {

public:

MyCriticalClass() {

puts("MyCriticalClass constructed manually!");

}

~MyCriticalClass() {

puts("MyCriticalClass destroyed!");

}

};

MyCriticalClass CriticalObj; // 这个对象的构造将由 InitializeMyObjects 控制

// 5. 在程序合适的地方（如DLL的初始化函数）调用手动初始化

int main() {

// ... 其他初始化代码 ...

InitializeMyObjects(); // 此时才会真正构造 CriticalObj

// ... 程序逻辑 ...

return 0;

}

`dll`相关

关于`dll`延迟加载

隐式加载
1. 一个dll的使用需要依赖头文件和Lib文件，直接以普通的接口的方式来调用dll的函数，这种方式就是隐式加载
  加载dll，链接了lib，这种情况lib是作为导入库，区别于加载静态库时lib是作为静态库
2. dll的隐式加载默认会在 mian 之前进行dll的加载工作
显示加载
1. 即dll的加载是通过 loadLibrary 实现，函数调用通过 GetProcAddress 来实现
延迟加载-显示加载
1. 对于DLL的显示加载实现延迟加载比较容易，因为LoadLibrary的调用时机可以通过代码来控制
延迟加载-隐式加载
1. 默认的隐式加载的dll是在mian函数发生之前触发，无法做到延迟加载
2. 但windows提供了一种解决方案，在工程项目中设置延迟加载的dll即可实现延迟加载
3. 链接器-输入-延迟加载的Dll
相关注意项
1. 延迟加载是针对隐式链接DLL的
2. 一个导出了字段（如全局变量)的DLL是无法延迟载入的
3. 系统的DLL一般都是无法延迟载入的，如Kernel32.dll
需要链接下面的库

1	delayimp.lib

`dll`双形态在不同系统的表现

在win10,win11，运行正常
在win7上面，调试发现，会在BuildRuntime内部这一行奔溃
1. 解决：
2. 调试发现，编出来的release开着优化时存在此问题，而禁用优化（/Od）后则不存在
3. 于是把release的优化关掉了来处理此问题

1	GET_ADDR(kernel32_module, GetModuleHandleW);

vs相关

符合模式

编译器选项
1. /permissive
2. 核心目标是让编译器以更严格的标准C++规则来检查你的代码
特点
1. 严格遵循C++标准，禁用大部分微软特定扩展
2. 严格，能识别并报告不符合标准的代码

`threadSafeInit`

开启
1. /Zc:threadSafeInit
2. 当代码首次执行到局部静态变量的声明时，编译器会插入额外的线程安全保证代码
3. 这通常涉及使用互斥锁或类似原子操作进行双重检查（Double-Checked Locking），确保即使多个线程同时调用，该变量也只会被初始化一次
禁用
1. /Zc:threadSafeInit-
2. 编译器会移除以保证线程安全而添加的同步机制
3. 意味着，如果多个线程在同一时刻首次访问该局部静态变量，可能会同时执行初始化代码，导致未定义行为
4. 常见后果包括重复构造对象、资源泄漏，或者更严重地，一个线程可能使用到另一个线程尚未完成初始化的对象，进而引发程序崩溃
配置属性-c/c++-命令行-附加选项

`strictStrings`

概述
1. 一个一致性模式设置，它直接影响编译器对字符串字面量类型转换的严格程度
开启
1. /Zc:strictStrings
2. 严格遵循 C++标准
3. 类型：严格，要求指针有 const限定
禁用
1. /Zc:strictStrings-
2. 宽松处理，允许非标准转换
3. 类型：宽松，允许字符串字面量赋值给非 const指针
配置属性-c/c++-命令行-附加选项

`rc`相关

`vs rc`里面覆盖资源的问题

资源视图添加了一张bitmap，png下面显示IDB_PNG_TEST
在png下面拷贝了IDB_PNG_TEST，生成了IDB_PNG_TEST1
修改了IDB_PNG_TEST1对应的ID和文件名
用同样的流程添加了很多张图片后发现，本地对应的其他图片被修改成第一张的内容

编译相关
#pragma init_seg
dll相关
关于dll延迟加载
dll双形态在不同系统的表现
vs相关
符合模式
threadSafeInit
strictStrings
rc相关
vs rc里面覆盖资源的问题

声明：本文为原创文章，版权归Aet所有，欢迎分享本文，转载请保留出处！

Bingliaolong 关注：0 粉丝：0

Everything will be better.

一	二	三	四	五	六	日
	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30

编译相关

`#pragma init_seg`

`dll`相关

关于`dll`延迟加载

`dll`双形态在不同系统的表现

vs相关

符合模式

`threadSafeInit`

`strictStrings`

`rc`相关

`vs rc`里面覆盖资源的问题

你可能也喜欢

热评文章

发表评论

标签云集

一些问题：vs相关、dll相关、编译相关

编译相关

#pragma init_seg

dll相关

关于dll延迟加载

dll双形态在不同系统的表现

vs相关

符合模式

threadSafeInit

strictStrings

rc相关

vs rc里面覆盖资源的问题

你可能也喜欢

热评文章

发表评论

标签云集

`#pragma init_seg`

`dll`相关

关于`dll`延迟加载

`dll`双形态在不同系统的表现

`threadSafeInit`

`strictStrings`

`rc`相关

`vs rc`里面覆盖资源的问题