LZ：16位编译器么？
提醒你，16位编译器是不提供64位int支持，建议你换用32位编译器。
而且16位编译器不适合进行大规模的数字的运算。（因为64K内存分页）
还有，你并没有“实现”一个64位整数，如果真的想实现int64，应该这样
typedef struct _int64_t
{
int32_t low,high;
} int64_t;
还要提醒你，UINT_MAX定义自limits.h，而intXX_t一系列类型是定义自stdint.h的。
从PFAN偷来的一段陈述：
1、TC不是标准。
应该承认，TC比较符合C89标准（上面那个例子算是例外）。但对于C99，TC力不从心。变长数组、复数支持、新的restrict等关键字，新的stdint.h等头文件，这些在TC中都没有看到。甚至，main函数不写return 0;还会有警告。
至于TC3.0，号称支持C++，但它甚至还不支持模版，这样的C++在今天看来已经不是C++了。同它开发C++工程更是个大笑话。
2、TC生成的代码效率不高。
大家知道TC生成的应用程序都运行于80x86平台，但如今的事实就是80x86正在进入64位时代。在TC中，一个double类型变量的赋值就要四条指令，一个16位整数的乘法就要占用两个寄存器（AX和DX），但在64位计算机上，以上动作都只需要一条指令。
另外，TC是基于单任务机制的，举个很简单的例子，如果我调用getch函数，则CPU会一直不停的检测键盘是否被按下，造成CPU时间的大量浪费。如果这个时候你还在用flashget下载，对不起，等我按完键盘再说。而现在的编译器大多都采用消息机制（通过操作系统实现），不存在以上问题。
至于语句优化，有一个很自然的事实：新一代的编译器会采用以前编译器所采用的各种优化手段，除非那样的手段并不合适。如果你不相信GCC或者VC比TC好，那么同为Borland出品的C++ Builder，总不会比它的先辈TC差吧？
手下见真章，大家把自己写的程序在TC和Dev-C++下分别运行，就知道效率的区别所在了。
3、TC生成的代码小是事实，但这个优势实在不明显。
以下面这个简单程序为例：
#include<stdio.h>
int main(void)
{
printf("Hello,World.\n");
getchar();
return 0;
}
TC编译连接，生成exe文件大小为9.45k。
Dev-C++编译连接，生成exe文件大小为16k。
请注意，TC程序总共可使用的空间只有1M，也就是说，1%的内存都被用来存放程序代码了。而Dev-C++在Windows平台，16k的大小完全可以接受。
4、TC的编辑环境不利于快速输入代码。
如果你用了VC，你会发现在输入一个函数名后打个括号，其参数信息就被显示出来了。如果你用了VS 2005中的C#代码编辑工具，你会发现一个变量名字只写一半，后一部分就被自动填出；该编辑器甚至还可以自动对齐格式。以上种种，有利于代码的快速输入，但TC呢？除了一个自动缩进，几乎就没有其他手段了。
5、TC稳定性不够好。
如果你在写程序的时候不小心乱用了指针，则当你把程序改到正确的时候，再运行，有可能仍然得不到正确结果，只有重新启动TC才能解决问题。你甚至可以通过指针把TC搞崩溃。并且当你再次进入TC时，以前的某些设置莫名其妙的被复原了。但在现代的编译器中，这样的问题非常少见。
6、TC并不是一无是处。
TC的帮助文档写得很规范，查询方便。编译速度和调试功能也很不错，但总的来说，这些优点总不足以弥补它其他方面的巨大不足。
结论：很明显，TC不是最好的编译器。
取自：http://www.
