什么时候使用size_t作为模板函数的参数是个坏主意

使用size_t作为模板参数没有错。

使用任何类型作为模板参数都没有错。

按您的意愿进行解释，但在Win32 API中为ReadFile()和许多其他函数编码时，TCC和GCC不会悄悄接受size_t或unsigned int。如果被指示，它必须是DWORD。没有例外。API refs非常明确地指出了这一点，否则编码很快就会告诉你他们是认真的。做任何不同的事情，你也会留下各种丑陋的铸造。

我觉得奇怪的是，我接受了那些我认为比我更了解size_t的人的支持。（大多数人都这样做，在一般的程序员中！）他们出于"可移植性"的原因支持size_t。奇怪的是，他们在决定什么是"可移植的"时没有考虑与Win32 API的兼容性。

事后看来，我自己的观点是，不允许这样的人对你说教。正如上面给出的"问题C"的简短回答所示，任何类型都可能有效。当然，重点是定义，意思是，我们应该知道我们选择了什么，以及为什么。通常有更大的理由来确定与某个主机匹配的代码的适当方法，例如程序的目的。没有任何类型，没有任何编译器能够为做出这些决定做好充分的准备。这是我们的工作。上下文就是一切，认为仅仅根据一个不知道我们在做什么的人的建议选择一种变量类型就可以实现最终的兼容性或可移植性是愚蠢的。网络越是破坏越来越多的浏览器和网站，这一点就越明显。

出于"可移植性"的原因，发明另一种"类型"最终与订购"一个环来绑定它们"一样有意义。

我能想到的唯一原因是size_t在32位和64位中的大小不同。如果您在某种序列化模板函数中使用它，那么在32位代码中序列化的数据将与64位代码不兼容。这更像是序列化size_t的问题，而不是模板特有的问题。如果你问你的教授，我很想听听他说什么！