为何Win32的SIZE结构体成员采用有符号类型？

1. 历史兼容性延续 #

Win32 API是从16位Windows系统演化而来，早在16位时代，与坐标、尺寸相关的结构就已经采用有符号类型设计。迁移到Win32平台时，为了兼容大量旧代码和既定的API调用习惯，SIZE结构体保留了LONG（有符号）类型的字段，避免因类型变更导致的大规模代码适配工作。

2. 实际场景存在负值需求 #

SIZE的cx和cy并非绝对不能为负，部分API场景中负值具备实际语义：

• 图形变换：在GDI、Direct2D等图形操作中，传入负的cx或cy可表示对图形进行水平/垂直镜像翻转，尺寸的正负同时携带了方向信息，无需额外参数标记变换方向。
• 相对计算简化：在布局、坐标转换逻辑中，负值可直接表示相对于基准点的反向偏移对应的尺寸，减少额外的方向判断代码，让计算逻辑更简洁。
• 关联结构的类型一致性：Win32中与坐标相关的核心结构（如POINT、RECT）均采用有符号类型，SIZE与其配合使用时，类型统一可避免频繁的类型转换，降低出错概率。例如RECT的right - left计算结果为有符号值，可直接赋值给SIZE.cx。

3. 为何不使用DWORD替代？ #

若改用无符号的DWORD，会引发一系列问题：

• 兼容性断裂：依赖负值逻辑的旧代码会直接出现行为异常或崩溃，大量现有软件需要修改适配。
• 计算逻辑复杂化：涉及尺寸减法、大小比较时，无符号类型容易产生溢出或非预期结果。比如smallerSize.cx - largerSize.cx会得到一个超大正数，而非预期的负数，需要额外添加判断逻辑处理。
• API语义不一致：与POINT、RECT等关联结构类型不统一，增加开发者的记忆负担和代码转换成本。

注意：虽然字段支持负值，但常规场景下应传入非负值，仅在明确的API语义要求下使用负值，误用可能导致未定义行为。

内容的提问来源于stack exchange，提问作者kevinarpe