ftest01 发表于 2011-7-21 09:39:32

很难理解为什么要把 rt_thread* 别名为 rt_thread_t

开始以为数据类型以_t结尾就代表这是一个指针型变量,但后来发现并不是这样,比如rt_uint32_t就不是一个指针型变量。
并不是说把 rt_thread* 别名为 rt_thread_t不可以,只是很容易误导阅读者。
比如:
    rt_thread_t thread;
    thread = rt_thread_create("led1", rt_thread_entry_led1, RT_NULL, 512, 20, 5);
这样读者很容易误解为rt_thread_t是一个复杂的结构体数据类型(类似TCB),而rt_thread_create()返回的就是一个该复杂结构体数据类型。
其实,改成下面的方法可能会更易于阅读:
    rt_thread* thread;
    thread = rt_thread_create("led1", rt_thread_entry_led1, RT_NULL, 512, 20, 5);
这样读者就很容易理解,rt_thread_create()返回的是一个指针型变量,而其指向的是一个复杂的结构体数据类型,改实例真正占用的内存空间是在rt_thread_create()函数内动态分配完成的,函数返回的就是该动态分配空间的地址。
个人愚见,欢迎拍砖,谢谢!

dr2001 发表于 2011-7-21 09:51:22

_t一般是Type的后缀,说明这个标识符是一个Type的名称。这个是从C标准一贯下来的。例如C标准规定的size_t,uint8_t,etc。

声明成rt_thread_t的对编码的好处是,用户不会随意对这个Type的变量进行操作,行为封闭。因为这里不需要用户了解rt_thread_t究竟代表什么,也不希望用户直接对它进行修改。

ftest01 发表于 2011-7-21 10:12:44

回复【1楼】dr2001
_t一般是type的后缀,说明这个标识符是一个type的名称。这个是从c标准一贯下来的。例如c标准规定的size_t,uint8_t,etc。
声明成rt_thread_t的对编码的好处是,用户不会随意对这个type的变量进行操作,行为封闭。因为这里不需要用户了解rt_thread_t究竟代表什么,也不希望用户直接对它进行修改。
-----------------------------------------------------------------------

正因为如此,我个人更加不推崇使用rt_thread_t这个别名,因为我们确实是需要知道rt_thread_t的具体含义是rt_thread*类型。
下面是rt_thread_create()的代码:
rt_thread_t    rt_thread_create(...,...,...)
{
    struct rt_thread* thread;
    ...
    ...
    return thread;
}
可以看到,我们定义的局部变量thread是一个rt_thread*指针型变量,而函数需要返回的是一个rt_thread_t型变量(此时读者很可能根本就不知道rt_thread_t是一个指针型变量,更不用说是一个指向rt_thread结构体的指针型变量了),如果系统编写者希望封装rt_thread_t数据类型,那此时读者就会比较puzzled。
说白了,作为代码阅读者,至少迫切需要知道,哪些变量是指针型变量,哪些变量是非指针型变量,这对理解代码和理解系统内存布局是至关重要的。

Cliff 发表于 2011-7-21 10:25:22

回复【2楼】ftest01
正因为如此,我个人更加不推崇使用rt_thread_t这个别名,因为我们确实是需要知道rt_thread_t的具体含义是rt_thread*类型。
说白了,作为代码阅读者,至少迫切需要知道,哪些变量是指针型变量,哪些变量是非指针型变量,这对理解代码和理解系统内存布局是至关重要的。
-----------------------------------------------------------------------

我问你,rtthread 是用来读代码重要,还是用来使用重要?
如果你是设计者,你会让你的代码偏向于让人读,还是让人用?

你的楼上dr2001,说的很有道理的,你不需要知道这个结构内部的事情,它对你来说只是一个资源,一个句柄。

ftest01 发表于 2011-7-21 10:28:42

我想,系统编写者大概是想表达这么一种意思。把rt_thread_t封装成类似Windows中句柄的概念,作为系统中表征该系统资源的唯一标识符。可我觉得,既然是在C/C++下编程,大可不必将其抽象到如此高度,反倒一定程度上影响了代码的可读性。

billwsy 发表于 2011-7-21 10:31:05

我同意LZ观点。代码可能还是要被其他人维护的,增加可读性仍然是有必要的。
不是很懂C,不知道C里面_t是被约定俗成表示一个类型,还是什么都可以表示。如果习惯上什么都表示的话那就另当别论了。

aozima 发表于 2011-7-21 10:32:04

我也不喜欢 rt_thread_t 代表 rt_thread*
很困惑.

如果是 rt_thread_p_t(这名字好丑) 或是 rt_thread *都好理解.
每次用到 **_t都得先跳到定义处确认一下到底是什么.

不过.已成既成事实. 先这样用了.

gzhuli 发表于 2011-7-21 10:55:49

在OS开发者的角度,当然希望清楚rt_thread_t是代表什么,不过OS开发者本身就应该很清楚这个定义的。
对于应用开发者,没有必要知道rt_thread_t里面是什么,因为里面可能包含很多系统内部信息,甚至不同平台有不同的定义,在运行过程中也随时可能被内核修改,过多暴露这些信息会影响OS可靠性和应用代码的可移植性。就像Windows的HANDLE,你不需要知道里面有什么,因为XP, Vista, Win7的HANDLE结构可能都不一样,对于应用程序,只管用就是了。
最后,对于想通过读代码了解RT-Thread内部运作的人,这个确实是有点困惑,习惯了就过去了。

ftest01 发表于 2011-7-21 11:11:11

回复【7楼】gzhuli 咕唧霖
在os开发者的角度,当然希望清楚rt_thread_t是代表什么,不过os开发者本身就应该很清楚这个定义的。
对于应用开发者,没有必要知道rt_thread_t里面是什么,因为里面可能包含很多系统内部信息,甚至不同平台有不同的定义,在运行过程中也随时可能被内核修改,过多暴露这些信息会影响os可靠性和应用代码的可移植性。就像windows的handle,你不需要知道里面有什么,因为xp, vista, win7的handle结构可能都不一样,对于应用程序,只管用就是了。
最后,对于想通过读代码了解rt-thread内部运作的人,这个确实是有点困惑,习惯了就过去了。
-----------------------------------------------------------------------

如果系统编写者下了决心永远只把rt_thread_t当做一个32位UINT句柄来看待的话,其实可以直接写明了
typedef struct rt_thread*    HANDLER_THREAD;
就是告诉应用程序编写者:忘了我是一个指向rt_thread的指针吧,我只是一个32位的整型变量,永远不要使用HANDLER_THREAD->xxx的用法,也不要使用((rt_thread *)HANDLER_THREAD)->xxx的用法。

Cliff 发表于 2011-7-21 11:34:35

回复【8楼】ftest01
-----------------------------------------------------------------------

你脑子怎么还转不过来呢?

1. typedef struct rt_thread*    HANDLER_THREAD;
2. typedef struct rt_thread*    rt_thread_t;

我问你,叫 HANDLER_THREAD 和 rt_thread_t 有什么区别啊?

ftest01 发表于 2011-7-21 11:37:38

回复【9楼】Cliff
回复【8楼】ftest01
-----------------------------------------------------------------------
你脑子怎么还转不过来呢?
1. typedef struct rt_thread*    handler_thread;
2. typedef struct rt_thread*    rt_thread_t;
我问你,叫 handler_thread 和 rt_thread_t 有什么区别啊?
-----------------------------------------------------------------------

没本质区别,纯粹是可读性上的区别,因为xxx_t实在是一个太普通的名字了。。。个人认为

gzhuli 发表于 2011-7-21 11:42:15

回复【8楼】ftest01
-----------------------------------------------------------------------

我基本上没看懂你在说什么。
typedef struct rt_thread* rt_thread_t;

typedef struct rt_thread* HANDLER_THREAD;
有什么区别?

是你非要将rt_thread_t理解成rt_thread*,那你也大可将HANDLER_THREAD理解成rt_thread*,那是不是这样定义更好:
typedef struct rt_thread* forget_what_i_am;

gzhuli 发表于 2011-7-21 11:48:20

回复【10楼】ftest01
没本质区别,纯粹是可读性上的区别,因为xxx_t实在是一个太普通的名字了。。。个人认为
-----------------------------------------------------------------------

普通的名字不是更加好让人忘了它原来是什么?
估计你属于闭源系统你用得好好的,开源系统一看源代码就晕的人。
如果RT-Thread独立发布个SDK,把struct rt_thread这些内核结构隐藏起来,对外直接声明typedef void* rt_thread_t,估计你就欢了吧。

dr2001 发表于 2011-7-21 11:56:03

回复【8楼】ftest01
-----------------------------------------------------------------------

系统设计者的本意就是rt_thread_t是一个Handler性质的东西,并且是用户不需要了解其实现的东西,所以typedef。

看来,你也同意开始的rt_thread_t .vs. rt_thread *问题已经解决了。

至于rt_thread_t的名字是不是足够好,这是另外一个事儿,如果你觉得不够好,完全可以咨询作者RT-Thread命名规则,提出改变命名的讨论话题。

ffxz 发表于 2011-7-21 11:57:25

_t指示出这是一个typedef

rt_thread_t指示出这是一个句柄

难道需要返回一个id给上层应用(例如这个id从0开始计数的),然后rt_thread_delay(id, 50)的时候,再根据id去查找一个thread tcb?慢!也有说,直接做为数组下标就可以索引了,问题是,系统中支持的线程、对象数目在编译时刻就固定了。

这个问题不需要做太多的争论,在编程指南中有相应的说明,这种对象指针_t性质的typedef,仅在内核中出现。

qqwuying2 发表于 2011-9-23 00:15:33

好激烈啊。。。。。。。。
页: [1]
查看完整版本: 很难理解为什么要把 rt_thread* 别名为 rt_thread_t