CPP，Winapi -WM_Create从lparam获得createstruct*的正确方法

CPP, WinAPI - WM_CREATE proper way to get CREATESTRUCT* from lParam

本文关键字：createstruct 方法 获得 lparam Winapi -WM Create CPP      更新时间：2023-10-16

Win32 API的某个教程使用此行将lParam参数从主窗口过程中的WM_CREATE消息转换为CREATESTRUCT*：

reinterpret_cast<CREATESTRUCT*>(lParam)  // Method 1

我在其他地方读到reinterpret_cast是危险的，导致行为不确定，闪电和其他。

我使用了更常规的演员，编译器没有抱怨：

(CREATESTRUCT*) lParam // Method 2

教程的作者是否有这样的理由？

，我确定有比我更好的方法吗？

在这种特殊情况下，这两种构造都是等效的。没有不确定的行为 - C 标准保证重新诠释指针指向足够宽的整数并返回导致相同的指针。

您可以安全地假设Windows从原始指针中创建了lParam值，就好像reinterpret_cast。

"（createstruct*）lparam" 表单称为c风格。使用此功能时，编译器将尝试所有可能的方法将表达式（lparam-此处）转换为类型（createstruct* - 在此）。

让我解释所有可能的铸造方法，

  1. 从" const/volatile t"铸造到t-在C 中，程序员使用 const_cast
    2. 选择此方式选择。
  2. 从" t"到" r"，其中t和r是相关的。例如。像int/char，汽车/车辆等 - 在C 中，程序员选择使用 static_cast 的铸造方式。
  3. 将t和r与运行时检查相关的" t"到" r"。例如。t =车辆和r =汽车，从t类型对象转换为r类型对象在静态上是有效的，但实际上（在运行时）编译器（通过隐藏的代码）必须检查被类型铸造的对象是否确实是汽车还是衍生物汽车。 - 在C 中，程序员选择使用 dynamic_cast 的铸造方式。
  4. 从" u"到" v"，其中u和v是无关的。 - 在C 中，程序员选择使用 reinterpret_cast 的铸造方式。

如果程序员在C 中使用C风格的铸件，他告诉编译器尝试所有可能的方法将表达式转换为/将表达式转换为/作为特定类型。

C风格演员是危险的唯一原因是，程序员的真正意图未正确传达给编译器和将要阅读代码的程序员。有时，程序员可能只意味着static_cast而不是retinterpret_cast，而是使用C风格的铸件会导致运行时的错误，这可能在编译时被捕获。因为如果程序员在无关类型上使用static_cast，则会发生编译器错误。

和用户定义的铸造操作员会影响一些行为（尤其是static_cast），但不会更改基本面。

相关文章：