使用 LIBCTINY.LIB 为 EXE 和 DLL 文件 减肥

核心提示： 你可能会担心这个LIBCTINY 是不完整的，举个例子，使用 LIBCTINY.LIB 为 EXE 和 DLL 文件 减肥(8)，在TEST.CPP 中，有个 strtchr 的调用，感谢Richard ，指出我的错误， 但是这些都没有问题，因为函数可以在 LIBC.LIB 或 LIBCM

你可能会担心这个LIBCTINY 是不完整的，举个例子，在TEST.CPP 中，有个 strtchr 的调用。 但是这些都没有问题，因为函数可以在 LIBC.LIB 或 LIBCMT.LIB 等 Visual C++ 提供的库中找到。 LIBCTINY.LIB 和 LIBC.LIB 都实现了一系列的函数，但是 LIBCTINY 显然要小得多。

最后，需要重申的是 LIBCTINY 并不适应所有的情况，比如，你使用了多线程，且使用了运行库的线程私有数据(译者著：指的是TLS-线程本地存储，比如为每个线程保留一个errno变量)的支持，LIBCTINY 就不合适，我一般是先试试，如果能够运转，那就太好了！如果不行，我就使用一般的运行库。

文章修正

在2000年十月的MSDN杂志上有篇我的文章 "Avoiding DLL Hell: Introducing Application Metadata in the Microsoft .NET Framework"。我写到：使用Visual C++ 6.0 #import 会使得编译器会读一个COM类型的库，并为所有库里面的接口产生一个 ATL 的头文件。同时指出 #import 产生了头文件，而不是 ATL。

Richard Grimes -- <<Professional ATL COM Programming (Wrox Press, 1998)>>的作者，友好地指出 #import 产生头文件为链接器支持的COM类，实际上是由 COMDEF.H 产生的。Richard 还说到，”链接器支持的COM类和ATL中支持的COM类有很多的不同。最大不同点就是ATL不使用C++异常。实际上，ATL类比链接器支持的COM类更加轻量级，所以我会很高兴用它来生成 ATL 代码。

我确实应该在我写之前多研究一下。我在 ATL方面的经验就仅限于 Visual C++ 的向导和自动生成的代码。我很少用#import ，没有足够的理由断言和 ATL 没有联系。感谢Richard ，指出我的错误，也会激励我以后做每件事情三思而后行。