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

ftest01

开始以为数据类型以_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

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

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

ftest01

回复【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

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

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

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

ftest01

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

billwsy

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

aozima

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

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

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

gzhuli

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

ftest01

回复【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

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

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

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

我问你，叫 HANDLER_THREAD 和 rt_thread_t 有什么区别啊？

ftest01

回复【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

回复【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

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

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

dr2001

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

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

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

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

ffxz

_t指示出这是一个typedef

rt_thread_t指示出这是一个句柄

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

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

qqwuying2

好激烈啊。。。。。。。。