typedef BOOL(WINAPI *MYFUNC) (HWND,COLORREF,BYTE,DWORD);语句的理解

本文详细介绍了C++中typedef的四大用途:定义类型别名、帮助旧代码中的struct声明、定义与平台无关的类型及简化复杂声明,并讨论了两个常见的陷阱。

首选先看一下typedef的四个用途和两个陷阱

用途一:
定义一种类型的别名,而不只是简单的宏替换。可以用作同时声明指针型的多个对象。比如:
char* pa, pb; // 这多数不符合我们的意图,它只声明了一个指向字符变量的指针, 
// 和一个字符变量;
以下则可行:
typedef char* PCHAR; // 一般用大写
PCHAR pa, pb; // 可行,同时声明了两个指向字符变量的指针
虽然:
char *pa, *pb;
也可行,但相对来说没有用typedef的形式直观,尤其在需要大量指针的地方,typedef的方式更省事。

用途二:
用在旧的C的代码中(具体多旧没有查),帮助struct。以前的代码中,声明struct新对象时,必须要带上struct,即形式为: struct 结构名 对象名,如:
struct tagPOINT1
{
int x;
int y;
};
struct tagPOINT1 p1;

而在C++中,则可以直接写:结构名 对象名,即:
tagPOINT1 p1;

估计某人觉得经常多写一个struct太麻烦了,于是就发明了:
typedef struct tagPOINT
{
int x;
int y;
}POINT;

POINT p1; // 这样就比原来的方式少写了一个struct,比较省事,尤其在大量使用的时候

或许,在C++中,typedef的这种用途二不是很大,但是理解了它,对掌握以前的旧代码还是有帮助的,毕竟我们在项目中有可能会遇到较早些年代遗留下来的代码。

用途三:
用typedef来定义与平台无关的类型。
比如定义一个叫 REAL 的浮点类型,在目标平台一上,让它表示最高精度的类型为:
typedef long double REAL; 
在不支持 long double 的平台二上,改为:
typedef double REAL; 
在连 double 都不支持的平台三上,改为:
typedef float REAL; 
也就是说,当跨平台时,只要改下 typedef 本身就行,不用对其他源码做任何修改。
标准库就广泛使用了这个技巧,比如size_t。
另外,因为typedef是定义了一种类型的新别名,不是简单的字符串替换,所以它比宏来得稳健(虽然用宏有时也可以完成以上的用途)。

用途四:
为复杂的声明定义一个新的简单的别名。方法是:在原来的声明里逐步用别名替换一部分复杂声明,如此循环,把带变量名的部分留到最后替换,得到的就是原声明的最简化版。举例:

1. 原声明:int *(*a[5])(int, char*);
变量名为a,直接用一个新别名pFun替换a就可以了:
typedef int *(*pFun)(int, char*); 
原声明的最简化版:
pFun a[5];

2. 原声明:void (*b[10]) (void (*)());
变量名为b,先替换右边部分括号里的,pFunParam为别名一:
typedef void (*pFunParam)();
再替换左边的变量b,pFunx为别名二:
typedef void (*pFunx)(pFunParam);
原声明的最简化版:
pFunx b[10];

3. 原声明:doube(*)() (*e)[9]; 
变量名为e,先替换左边部分,pFuny为别名一:
typedef double(*pFuny)();
再替换右边的变量e,pFunParamy为别名二
typedef pFuny (*pFunParamy)[9];
原声明的最简化版:
pFunParamy e;

理解复杂声明可用的“右左法则”:
从变量名看起,先往右,再往左,碰到一个圆括号就调转阅读的方向;括号内分析完就跳出括号,还是按先右后左的顺序,如此循环,直到整个声明分析完。举例:
int (*func)(int *p);
首先找到变量名func,外面有一对圆括号,而且左边是一个*号,这说明func是一个指针;然后跳出这个圆括号,先看右边,又遇到圆括号,这说明(*func)是一个函数,所以func是一个指向这类函数的指针,即函数指针,这类函数具有int*类型的形参,返回值类型是int。
int (*func[5])(int *);
func右边是一个[]运算符,说明func是具有5个元素的数组;func的左边有一个*,说明func的元素是指针(注意这里的*不是修饰func,而是修饰func[5]的,原因是[]运算符优先级比*高,func先跟[]结合)。跳出这个括号,看右边,又遇到圆括号,说明func数组的元素是函数类型的指针,它指向的函数具有int*类型的形参,返回值类型为int。

也可以记住2个模式:
type (*)(....)函数指针 
type (*)[]数组指针 
---------------------------------

陷阱一:
记住,typedef是定义了一种类型的新别名,不同于宏,它不是简单的字符串替换。比如:
先定义:
typedef char* PSTR;
然后:
int mystrcmp(const PSTR, const PSTR);

const PSTR实际上相当于const char*吗?不是的,它实际上相当于char* const。
原因在于const给予了整个指针本身以常量性,也就是形成了常量指针char* const。
简单来说,记住当const和typedef一起出现时,typedef不会是简单的字符串替换就行。

陷阱二:
typedef在语法上是一个存储类的关键字(如auto、extern、mutable、static、register等一样),虽然它并不真正影响对象的存储特性,如:
typedef static int INT2; //不可行
编译将失败,会提示“指定了一个以上的存储类”。

 

 

typedef BOOL(WINAPI *MYFUNC) (HWND,COLORREF,BYTE,DWORD);

这条语句的出处,是在学习透明窗体时,不知是哪位牛人写的一段典型代码,如下

SetWindowLong(this->GetSafeHwnd(),GWL_EXSTYLE,
  GetWindowLong(this->GetSafeHwnd(),GWL_EXSTYLE)^0x80000);
 HINSTANCE hInst = LoadLibrary(L"User32.DLL");
 if(hInst) 
 { 
  typedef BOOL(WINAPI* MYFUNC) (HWND,COLORREF,BYTE,DWORD);  

  MYFUNC  fun = NULL;
  //取得SetLayeredWindowAttributes函数指针     
  fun=(MYFUNC)GetProcAddress(hInst, "SetLayeredWindowAttributes");   
  if(fun)
   fun(this->GetSafeHwnd(), 0, 125, 2);     
  FreeLibrary(hInst);   
 }

经过我的修改后如下

 SetWindowLong(this->GetSafeHwnd(),GWL_EXSTYLE,
  GetWindowLong(this->GetSafeHwnd(),GWL_EXSTYLE)^0x80000);
 HINSTANCE hInst = LoadLibrary(L"User32.DLL");
 if(hInst) 
 { 
  BOOL (WINAPI* fun) (HWND,COLORREF,BYTE,DWORD); 


  //取得SetLayeredWindowAttributes函数指针

  (PROC&)fun = GetProcAddress(hInst,"SetLayeredWindowAttributes");
  
  if(fun)
   fun(this->GetSafeHwnd(), 0, 125, 2);     
  FreeLibrary(hInst);   
 }

 

(PROC&)这是转换左值。
比如一段程序:
int a;
a = 1;  // 在这个赋值语句里:   
              请看,等号左边是什么类型呢?  不是整数型,因为  2=3 这句话不能通过编译,等号左边是整数的左值类型,也就是   (int  l-value ),  其中左值是通过语义指出的,语法上你只需写出int&就可以,用&来代替左值引用,这是一个规定。

转载于:https://www.cnblogs.com/cwbo-win/articles/3408659.html

<think>我们正在讨论在Linux和Windows之间移植代码时,关于`typedefBOOLnear*PBOOL`的定义和兼容性问题。首先,需要理解这个typedef的含义:-在Windows环境下,`near`是一个旧式的内存模型关键字,用于16位架构,表示指针是近指针(在同一个段内)。在32位和64位系统中,所有指针都是平坦地址(flataddress),因此`near`关键字变得无关紧要且被忽略。-`BOOL`是Windows中定义的一个类型,通常为`int`(在Windows中,FALSE为0,TRUE为1)。-`PBOOL`是指向BOOL的指针。然而,在Linux环境中,并没有`near`关键字(这是旧版Windows编程中特有的)。同样,Linux下也没有原生的`BOOL`类型定义(但通常可以通过`<stdbool.h>`使用`bool`类型,或者自定义类似Windows的`BOOL`)。因此,在移植时,我们需要考虑以下几点:1.`near`关键字:在32位及以上的Windows系统中,`near`已经被忽略,但在Linux中,这个关键字是不存在的。因此,在跨平台代码中,我们需要确保移除或重新定义这些与内存模型相关的关键字。2.`BOOL`类型:在Windows中,`BOOL`是一个整数类型(通常是int)。在Linux中,我们可以自定义一个`BOOL`类型,或者使用C99标准的`bool`(需要包含`<stdbool.h>`),但注意Windows的`BOOL`和C99的`bool`大小可能不同(`BOOL`是4字节,`bool`是1字节),并且TRUE/FALSE的值也可能有细微差别(Windows中TRUE是1,而C99中true是1;但注意在Windows中任何非零值都是TRUE,而C99中true就是1)。具体到`typedefBOOLnear*PBOOL`:-这个定义在32位/64位Windows中相当于`typedefBOOL*PBOOL`,因为`near`被忽略。-在Linux中,我们需要一个等价定义。解决方案:1.我们可以为跨平台代码创建一个头文件,在其中根据平台进行条件编译。2.对于`near`关键字,在非16位Windows平台(即我们现在的目标平台)中,我们可以将`near`定义为空宏。3.对于`BOOL`类型,我们可以使用与Windows相同的定义(即`int`),或者使用C99的`bool`,但需要注意使用场景(比如与WindowsAPI交互时可能需要Windows定义的`BOOL`)。示例头文件(例如:compatibility.h)可能如下:```c#ifndefCOMPATIBILITY_H#defineCOMPATIBILITY_H#ifdefined(_WIN32)||defined(_WIN64)//在Windows平台上,包含Windows.h以获得标准定义#include<Windows.h>#else//在Linux或其他平台//定义与Windows兼容的BOOL类型typedefintBOOL;#defineTRUE1#defineFALSE0//将near定义为空,因为现代编译器不再需要它#definenear#endif//定义PBOOL,注意在非Windows平台上我们使用自己定义的BOOLtypedefBOOLnear*PBOOL;#endif//COMPATIBILITY_H```但是,请注意:-在Windows上,我们包含了`Windows.h`,它已经定义了`BOOL`、`PBOOL`等类型。因此,在Windows上我们不需要重复定义。-在非Windows平台上,我们定义了`BOOL`为`int`,并定义了`TRUE`和`FALSE`。同时,将`near`定义为空,这样`typedefBOOLnear*PBOOL`就变成了`typedefBOOL*PBOOL`,即指向BOOL的指针。然而,在Windows中,`PBOOL`已经通过`Windows.h`定义,所以我们的头文件可能会造成重复定义。为了避免重复定义,我们可以:```c#ifndefCOMPATIBILITY_H#defineCOMPATIBILITY_H#ifdefined(_WIN32)||defined(_WIN64)#include<Windows.h>#elsetypedefintBOOL;#defineTRUE1#defineFALSE0#definenear//定义为空#endif//如果未定义PBOOL,则定义它#ifndefPBOOLtypedefBOOLnear*PBOOL;#endif#endif```但是,在Windows中,`Windows.h`已经定义了`PBOOL`(实际上,在Windows中,`PBOOL`是存在的,但请注意,Windows通常使用`LPBOOL`(长指针)和`PBOOL`(近指针)?实际上在32位以上,两者相同。在Windows中,`PBOOL`可能没有定义,但`BOOL*`可以直接使用。实际上,在`Windows.h`中,`PBOOL`可能是这样定义的:`typedefBOOL*PBOOL;`)。因此,为了避免重复定义,我们可以不在非Windows平台上定义`PBOOL`,而是使用条件编译。实际上,在Windows中,`PBOOL`已经定义,所以我们不需要再次定义。我们可以只在非Windows平台定义我们需要的类型。另一种做法是:在跨平台代码中,尽量避免使用这些特定于Windows的类型,而是使用标准C类型(例如`int*`)。但如果需要与现有Windows代码兼容,或者使用一些跨平台库(如GTK、Qt等),则可能需要处理这些类型。另外,注意在Linux下,我们通常不会使用`near`和`far`这些关键字,所以将它们定义为空宏是安全的。总结:-在32位/64位系统中,`near`和`far`关键字已经过时,可以忽略。-在跨平台代码中,通过条件编译处理平台相关的类型定义。-在Linux中,自定义`BOOL`和`PBOOL`等类型,并确保将`near`等关键字定义为空。这样,代码就可以在Linux和Windows之间移植。注意:如果代码中大量使用了Windows特有的类型,可能需要更全面的兼容层(如Wine中的头文件),但这里我们只处理了`BOOL`和`PBOOL`。最后,关于原始问题中的`typedefBOOLnear*PBOOL`,在移植时,我们只需要确保在非Windows平台有相应的定义,并且消除`near`关键字的影响即可。相关问题:1.在32位和64位系统中,为什么`near`和`far`关键字不再需要?2.除了`BOOL`,还有哪些Windows数据类型在Linux中需要特殊处理?3.在跨平台编程中,还有哪些其他常见的问题需要注意?</think>### Windows与Linux代码移植:`typedef BOOL near *PBOOL`的兼容性分析 #### 1. **Windows环境下的定义解析** - **`BOOL`类型** Windows中`BOOL`是基础布尔类型,本质是`int`的别名: ```c typedef int BOOL; // TRUE=1, FALSE=0 ``` - **`near`关键字** 这是16位Windows时代的遗留概念(基于分段内存模型): - `near`表示**16位近指针**(同一代码段内的短指针) - 在32位/64位Windows中已完全废弃(所有指针均为平坦地址) - 现代Windows编译器(MSVC)会直接忽略`near`关键字 - **`PBOOL`类型** 最终等效定义: ```c typedef BOOL* PBOOL; // 指向BOOL的指针 ``` #### 2. **Linux兼容性问题** - ⚠️ **`near`关键字不兼容** Linux编译器(GCC/Clang)**无`near`关键字支持**,直接使用会导致编译错误: ```bash error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token ``` - ⚠️ **`BOOL`类型差异** Linux默认无`BOOL`定义,需手动实现: ```c // Linux常见实现方式 typedef enum { FALSE = 0, TRUE = 1 } BOOL; ``` #### 3. **跨平台移植解决方案** ##### 方案1:条件编译(推荐) ```c #ifdef _WIN32 #include <Windows.h> // 使用原生Windows定义 #else // Linux兼容层 typedef int BOOL; #define FALSE 0 #define TRUE 1 typedef BOOL* PBOOL; // 直接忽略near #endif ``` ##### 方案2:标准化替代 ```c // 完全避免Windows特有类型 #include <stdbool.h> // C99标准布尔类型 bool* pFlag; // 替代PBOOL ``` #### 4. **兼容性验证** | 组件 | Windows | Linux | 解决方案 | |-------------|------------------|------------------|----------------------------| | `BOOL` | ✅ `int`别名 | ❌ 未定义 | 条件编译或`stdbool.h` | | `near` | ⚠️ 废弃(忽略) | ❌ 语法错误 | 完全移除 | | `*PBOOL` | ✅ 普通指针 | ✅ 普通指针 | 统一为`BOOL*` | #### 5. **移植注意事项** 1. **内存模型差异** 所有`near/far`修饰符需删除,现代系统均为平坦地址空间[^1]。 2. **类型严格性** Linux下建议使用`stdbool.h`的`bool`(1字节),而Windows的`BOOL`是4字节`int`。 3. **API替代** 如涉及Windows API(如`IsWindow()`),需用Linux等效实现(如GTK/Qt的窗口判断)。 > **关键结论**:`near`是主要移植障碍,直接移除后配合条件编译即可实现跨平台兼容。建议优先使用C99标准类型替代Windows特有类型[^2]。 --- ### 相关问题 1. 在Linux中如何实现与Windows API等效的布尔值检查? 2. 除了`BOOL`,还有哪些Windows数据类型在Linux移植时需要特殊处理? 3. 如何设计跨平台头文件以兼容Windows和Linux的内存模型差异? 4. 现代C/C++开发中是否应完全避免使用`near/far`等遗留关键字? [^1]: Windows数据类型源于16位分段内存架构,`near/far`在32位后失效。 [^^2]: MFC早期已关注跨Windows版本移植性,但未解决OS间兼容问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值