UC知道一个关于MFC本身的设计的问题
来源：百度知道 编辑：UC知道 时间：2024/06/04 05:27:06
关于类型的typedef和值的#define，我知道能让意图更明显
比如
typedef int HEIGHT;
typedef int NUM;
HEIGHT a=xxx;
NUM b=xxx;
我们很容易区分a和b的意义。虽然其实都是int.
在MFC中，用到了很多，也非常清晰。但是唯一有一点不明白：
我看到是这么设计的
比如一个类的一个函数fun(KEY _key)
他接受一个KEY
而
typedef int KEY;
值这么定义
#define KEY_A 100;
#define KEY_B 101;
...
这样，一般调用fun的时候，我们fun(KEY_x);
这里的KEY类型为什么不用enum呢
enum KEY
{
KEY_A=100,
KEY_B,
KEY_C,
...
};
这样不更有类型安全性么？
不然别人可以fun(1);
需要在fun里边做类型范围检测。
为什么这么设计呢？有其中特殊的原因么？
logo0775的回答,我不敢苟同，#define是预编译阶段替换值，是c中采用的类似const的方法，c++中建议使用const来提供更多的类型安全，当然#define有其另外的用途。不说这个了，还是回到主题，这个问题仍然没有得到解答。我在设计自己的框架的时候，建立类型机制，一些功能函数他们原本是不需要返回值得（void），我会enum一个类型，用来做这批函数的返回值，里边的值可以提供函数运行情况，比如在我写过的一个虚拟linux文件系统中，各种函数处理可能意外碰到诸如路径问题，文件没有找到，磁盘分配表错误，所以不采用void,我也不喜欢用bool,因为提供的信息太少，而是用一个enum，里边列举了各种问题和情况。
比如
typedef int HEIGHT;
typedef int NUM;
HEIGHT a=xxx;
NUM b=xxx;
我们很容易区分a和b的意义。虽然其实都是int.
在MFC中，用到了很多，也非常清晰。但是唯一有一点不明白：
我看到是这么设计的
比如一个类的一个函数fun(KEY _key)
他接受一个KEY
而
typedef int KEY;
值这么定义
#define KEY_A 100;
#define KEY_B 101;
...
这样，一般调用fun的时候，我们fun(KEY_x);
这里的KEY类型为什么不用enum呢
enum KEY
{
KEY_A=100,
KEY_B,
KEY_C,
...
};
这样不更有类型安全性么？
不然别人可以fun(1);
需要在fun里边做类型范围检测。
为什么这么设计呢？有其中特殊的原因么？
logo0775的回答,我不敢苟同，#define是预编译阶段替换值，是c中采用的类似const的方法，c++中建议使用const来提供更多的类型安全，当然#define有其另外的用途。不说这个了，还是回到主题，这个问题仍然没有得到解答。我在设计自己的框架的时候，建立类型机制，一些功能函数他们原本是不需要返回值得（void），我会enum一个类型，用来做这批函数的返回值，里边的值可以提供函数运行情况，比如在我写过的一个虚拟linux文件系统中，各种函数处理可能意外碰到诸如路径问题，文件没有找到，磁盘分配表错误，所以不采用void,我也不喜欢用bool,因为提供的信息太少，而是用一个enum，里边列举了各种问题和情况。
没有什么特殊原因。
是因为程序设计者想卖弄他那点知识，所以就用到了这些操作符而已。
只要明白了 typedef 和 define的含义，随便你怎么用都行
用了enum值就不能变了.
用#define定义,可以变.
你们都是高手，我才进来看看，这个问题也经典啊！
enum是固定的
#define是可以自己定义的
typedef 和 define 搞完后就像写htm代码一样了，想怎么写就怎么写