C Runtime Library 的来历
msvcrt.dll (名称:Microsoft C Runtime Library)提供了printf,malloc,strcpy等C语言库函数,并且为使用C/C++(Vc)编绎的程序提供了初始化(如获取命令行参数)以及退出等功能.
C Runtime Library 的来历, API, STL, MFC, ATL关系
刚接触Windows开发时，为了快速入门查了不少资料，没想到看的越多，脑袋越糊涂。因为写同一种功能的程序，找到的例程风格截然不同。拿C程序来说，有些API的名称都很长，都是没见过的变量类型而且全大写；有些跟熟悉的Linux环境C开发差不多，标准短小的C函数名。再比如某些C++程序，用的标准类也会有不同。后来专门花了点功夫，才了解Windows平台下的开发有多个不同的体系：标准C，Windows API，MFC，STL。这些都是预先编写好的库，实际开发时选哪个，取决于项目的规模和性质、程序的风格，还有个人的喜好。
一、自由世界中的C\C++
1. CRT
运行时库就是C Run-Time Library，是C而非C++语言世界的概念。取这个名字就是因为你的C程序运行时需要这些库中的函数。
C语言是所谓的“小内核”语言，就其语言本身来说很小（不多的关键字，程序流程控制，数据类型等）；所以，C语言内核开发出来之后， Dennis Ritchie 和 Brian Kernighan 就用C本身重写了 90% 以上的 UNIX 系统函数，并且把其中最常用的部分独立出来，形成头文件和对应的 LIBRARY，C run-time library 就是这样形成的。
随后，随着C语言的流行，各个C编译器的生产商/个体/团体都遵循老的传统，在不同平台上都有相对应的 Standard Library，但大部分实现都是与各个平台有关的。由于各个C编译器对C的支持和理解有很多分歧和微妙的差别，所以就有了ANSI C；ANSI C（主观意图上）详细的规定了 C 语言各个要素的具体含义和编译器实现要求，引进了新的函数声明方式，同时订立了 Standard Library 的标准形式。所以C运行时库由编译器生产商提供。至于由其他厂商/个人/团体提供的头文件和库函数，应当称为第三方 C 运行库（Third party C run-time libraries）。
C Run-Time Library里面含有初始化代码，还有错误处理代码(例如divide by zero处理)。你写的程序可以没有 math库，程序照样运行，只是不能处理复杂的数学运算，不过如果没有了C Run-Time Library，main()就不会被调用，exit()也不能被响应。因为C Run-Time Library包含了C程序运行的最基本和最常用的函数。
2. Standard C++ Library
到了 C++ 世界里，有另外一个概念:Standard C++ Library，它包括了上面所说的C Run-Time Library和STL。包含C Run-Time Library的原因很明显，C++ 是 C 的超集，没有理由再重新来一个 C ++ run-time library。VC针对C++ 加入的Standard C++ Library主要包括：LIBCP.LIB, LIBCPMT.LIB和 MSVCPRT.LIB。
二、Microsoft的C\C++
1. Windows中的CRT
CRT原先是指Microsoft开发的C Runtime Library，用于操作系统的开发及运行。后来在此基础上开发了C++ Runtime Library，所以现在CRT是指Microsoft开发的C/C++ Runtime Library。在VC的CRT/SRC目录下，可以看到CRT的源码，不仅有C的，也有C++的。
CRT原先的目的就是支持操作系统的运行。因为Windows操作系统除汇编部分外，都是用C/C++编写的，所以内核及许多关键服务都在CRT上运行（它们都采用dll技术动态链接）。此外，用 VC编写的C/C++程序也用到它们（可以动态链接，也可以静态链接，前者运行时需要系统中已安装CRT的dll，后者不需要）。可以说，CRT就是 Microsoft编写Windows时使用的低层类库。然后，它又被当作C++标准库的一个实现包含在了VC系列中；我们在VC中使用的C++标准库，其实就是CRT的一个真子集（少了C++标准所不包含的代码，特别是大量的低层C代码）
C++标准，是C++的通用语言规范，指导所有C ++使用者。而CRT的其中一部分可以看作是Microsoft开发的一个C++标准库实现（其实也确实如此，Microsoft在开发CRT时，参考了正在标准化过程中的C++语言规范）。它与C++标准有一定的差距，部分原因是，在C++没有完成标准化之前，CRT已经开发并投入使用了。为了向下兼容以前的Windows代码，早期的CRT与C++标准总有一定的差距。但是CRT确实在不断的改进中。VC6带的CRT与C++标准还有比较大的差距，而 VC8的几乎完全符合C++标准了。
2. Windows中的CRT与Windows API
至于CRT与WINDOWS API的关系，与许多人理解的相反，WINDOWS API作为Windows的一部份，是在CRT的基础上开发的。你可以将Windows（及其API）看作一个项目，而这个项目使用的语言是汇编/C/C ++，使用的类库就是CRT。所以，离开CRT，Windows API也无法使用的。
在编写操作系统时，你需要一个合适的低层库，以便完成一些基本的、多次重复的工作。于是，就有了CRT。在最低层的时候，根本连DLL这个概念都没有的，所以CRT的源代码只能做成lib，被静态链接。然后，随着Windows越做越复杂，Microsoft提出了API的概念，它提供Windows开发者一组接口，可以直接操作Windows，这就是Windows API了。当然，Windows API也是在CRT之上编写的。
接着，Microsoft想给予C/C++程序员以足够的支持，除了原始CRT之外，还要增加在Windows平台上编程所特有的东西，如thread等等。这些东西都是和平台相关的，只能建立在Windows API上。而这些新增内容，也被放进了CRT中。此时，CRT不仅仅包含最低层平台无关的代码，还包括平台相关的部分。如你调用CRT的 _beginthread，其实内部调用了Windows API的CreateThread。加入这些东西后，CRT仍然被用作编写操作系统；但是显然，那些调用了Windows API的部分已经失去移值性了。
然后，CRT被封装成产品，随编译器一起发布。此时CRT产品的LIB和DLL都是Windows格式的，你不能在Windows以外的平台上使用EXE或DLL吧，这就是CRT和CRT产品的区别。Windows API的产品，或是Windows的其他许多组成部分也是一些LIB/DLL文件，这些都是表面的东西，是与Windows绑定在一起的。但是，如果你认为是先有Windows或Windows API，才有CRT的，那你就本末倒置了。除非你对CRT的定义就是那些LIB/DLL产品，而不包括用来产生它们的代码。
当然，CRT的一些组成部分也调用了Windows API。这可能就是有人认为CRT是建立的Windows API基础上的原因。但是实际上，这一部分剥离CRT没有任何的问题。只不过Microsoft将在Windows平台上可以使用的C/C++低层库都加入到CRT中。因此，CRT中很大一部分是操作系统平台无关的（原始的CRT），是开发Windows本身及其上一切的基础。它们也可以作为一个C/C+ +库在其他操作系统平台上使用。还有一部分，则是和Windows紧密绑定的，调用Windows API来实现的，可以看作扩展的CRT。之所以将这两部分放在一起，是因为它们都是开发Windows操作系统所需要的，也因为它们也都是Windows 平台上的C/C++程序员所需要的。这种复杂关系是Microsoft的人为因素造成的，不能因此认为CRT是建立在Windows或Windows API基础上的。
综上，CRT（Microsoft's C/C++ Runtime Library）的一个真子集（主要是C++ Runtime Library）是一个符合（或至少是企图符合）C++标准的C++库。而Windows API（以及Windows的其他许多部分）都是在CRT的基础上开发的。
最后再说一句，C++当然不是Microsoft的专利。但是Microsoft选择了C++，并取得了成功，这是肯定的了：象CRT，象VC，象Windows，象Office，象 SQL Server等等。这一方面说明了C++的优势，一方面也是Microsoft自身的因素在起作用。然后，它当然要紧抓C++的大旗，大力宣扬它自己的C++，并排斥其他的C++。这就是帝国的“风范”了。所以对Microsoft，总是即恨且爱，总希望哪天它会良心发现——当然这只是幻想罢了。不过，肯定该肯定的，否定该否定的，总是应该的。但就产品而言，Microsoft不是最好的，但大多都是最成功的，在看到它的不足的同时，也要看到它的优点。存在的即使不是合理的，也一定有它的合理性。所以，不能简单用一两句话评价Microsoft及它的成功。惟有一点是可以肯定的，它决定选择C ++，真是太英明了！
=================================================================================================
1)运行时库就是 C run-time library，是 C 而非 C++ 语言世界的概念:取这个名字就是因为你的 C 程序运行时需要这些库中的函数.
2)C 语言是所谓的“小内核”语言，就其语言本身来说很小（不多的关键字，程序流程控制，数据类型等）；所以，C 语言内核开发出来之后， Dennis Ritchie 和 Brian Kernighan 就用 C 本身重写了 90% 以上的 UNIX 系统函数，并且把其中最常用的部分独立出来，形成头文件和对应的 LIBRARY，C run-time library 就是这样形成的。
3)随后，随着 C 语言的流行，各个 C 编译器的生产商/个体/团体都遵循老的传统，在不同平台上都有相对应的 Standard Library，但大部分实现都是与各个平台有关的。由于各个 C 编译器对 C 的支持和理解有很多分歧和微妙的差别，所以就有了 ANSI C；ANSI C （主观意图上）详细的规定了 C 语言各个要素的具体含义和编译器实现要求，引进了新的函数声明方式，同时订立了 Standard Library 的标准形式。所以C运行时库由编译器生产商提供。至于由其他厂商/个人/团体提供的头文件和库函数，应当称为第三方 C 运行库（Third party C run-time libraries）。
4)C run-time library里面含有初始化代码，还有错误处理代码(例如divide by zero处理)。你写的程序可以没有 math库，程序照样运行，只是不能处理复杂的数学运算，不过如果没有了C run-time库，main()就不会被调用，exit()也不能被响应。因为C run-time library包含了C程序运行的最基本和最常用的函数。
5)到了 C++ 世界里，有另外一个概念:Standard C++ Library,它包括了上面所说的 C run- time library 和 STL。包含 C run-time library 的原因很明显，C++ 是 C 的超集，没有理由再重新来一个 C ++ run-time library. VC针对C++ 加入的Standard C++ Library主要包括：LIBCP.LIB, LIBCPMT.LIB和 MSVCPRT.LIB
6)Windows环境下，VC提供的 C run-time library又分为动态运行时库和静态运行时库。
动态运行时库主要是DLL库文件msvcrt.dll(or MSVCRTD.DLL for debug build),对应的Import library文件是MSVCRT.LIB(MSVCRTD.LIB for debug build)
静态运行时库(release版)对应的主要文件是：
LIBC.LIB (Single thread static library, retail version)
LIBCMT.LIB (Multithread static library, retail version)
msvcrt.dll提供几千个C函数，即使是像printf这么低级的函数都在msvcrt.dll里。其实你的程序运行时，很大一部分时间时在这些运行库里运行。在你的程序(release版)被编译时，VC会根据你的编译选项(单线程、多线程或DLL)自动将相应的运行时库文件 (libc.lib,libcmt.lib或Import library msvcrt.lib)链接进来。
编译时到底哪个C run-time library联入你的程序取决于编译选项：
/MD, /ML, /MT, /LD (Use Run-Time Library)
你可以VC中通过以下方法设置选择哪个C run-time library联入你的程序：
To find these options in the development environment, click Settings on the Project menu. Then click the C/C++ tab, and click Code Generation in the Category box. See the Use Run-Time Library drop-down box.
从程序可移植性考虑,如果两函数都可完成一种功能，选运行时库函数好,因为各个 C 编译器的生产商对标准C Run-time library提供了统一的支持.
======================================================================================================
关于STL
从逻辑层次来看，在STL中体现了泛型化程序设计的思想（generic programming），引入了诸多新的名词，比如像需求（requirements），概念（concept），模型（model），容器（container），算法（algorithmn），迭代子（iterator）等。与OOP（object-oriented programming）中的多态（polymorphism）一样，泛型也是一种软件的复用技术。
在你了解了STL的过去之后，一些名词开始不断在你的大脑中浮现，STL、C++、C++标准函数库、泛型程序设计、面向对象程序设计……，这些概念意味着什么？他们之间的关系又是什么？如果你想了解某些细节，这里也许有你希望得到的答案。
1. STL和C++
没有C++语言就没有STL，这么说毫不为过。一般而言，STL作为一个泛型化的数据结构和算法库，并不牵涉具体语言（当然，在C++里，它被称为STL）。也就是说，如果条件允许，用其他语言也可以实现之。这里所说的条件，主要是指类似于"模板"这样的语法机制。如果你没有略过前一节内容的话，应该可以看到，Alexander Stepanov在选择C++语言作为实现工具之前，早以采用过多种程序设计语言。但是，为什么最终还是C++幸运的承担了这个历史性任务呢？原因不仅在于前述那个条件，还在于C++在某些方面所表现出来的优越特性，比如：高效而灵活的指针。但是如果把C++作为一种OOP（Object-Oriented Programming，面向对象程序设计）语言来看待的话（事实上我们一般都是这么认为的，不是吗？），其功能强大的继承机制却没有给STL的实现帮上多大的忙。在STL的源代码里，并没有太多太复杂的继承关系。继承的思想，甚而面向对象的思想，还不足以实现类似STL这样的泛型库。C++只有在引入了"模板"之后，才直接导致了STL的诞生。这也正是为什么，用其他比C++更纯的面向对象语言无法实现泛型思想的一个重要原因。当然，事情总是在变化之中，像Java在这方面，就是一个很好的例子，jdk1.4中已经加入了泛型的特性。
此外，STL对于C++的发展，尤其是模板机制，也起到了促进作用。比如：模板函数的偏特化（template function partial specialization），它被用于在特定应用场合，为一般模板函数提供一系列特殊化版本。这一特性是继STL被ANSI/ISO C++标准委员会通过之后，在Bjarne和Stepanov共同商讨之下并由Bjarne向委员会提出建议的，最终该项建议被通过。这使得STL中的一些算法在处理特殊情形时可以选择非一般化的方式，从而保证了执行的效率。
1.1 STL和C++标准函数库
STL是最新的C++标准函数库中的一个子集，这个庞大的子集占据了整个库的大约80%的分量。而作为在实现STL过程中扮演关键角色的模板则充斥了几乎整个C++标准函数库。在这里，我们有必要看一看C++标准函数库里包含了哪些内容，其中又有哪些是属于标准模板库（即STL）的。
C++标准函数库为C++程序员们提供了一个可扩展的基础性框架。我们从中可以获得极大的便利，同时也可以通过继承现有类，自己编制符合接口规范的容器、算法、迭代子等方式对之进行扩展。它大致包含了如下几个组件：
C标准函数库，基本保持了与原有C语言程序库的良好兼容，尽管有些微变化。人们总会忍不住留恋过去的美好岁月，如果你曾经是一个C程序员，对这一点一定体会颇深。或许有一点会让你觉得奇怪，那就是在C++标准库中存在两套C的函数库，一套是带有.h扩展名的（比如<stdio.h>），而另一套则没有（比如<cstdio>）。它们确实没有太大的不同。
语言支持（language support）部分，包含了一些标准类型的定义以及其他特性的定义，这些内容，被用于标准库的其他地方或是具体的应用程序中。
诊断（diagnostics）部分，提供了用于程序诊断和报错的功能，包含了异常处理（exception handling），断言（assertions），错误代码（error number codes）三种方式。
通用工具（general utilities）部分，这部分内容为C++标准库的其他部分提供支持，当然你也可以在自己的程序中调用相应功能。比如：动态内存管理工具，日期/时间处理工具。记住，这里的内容也已经被泛化了（即采用了模板机制）。
字符串（string）部分，用来代表和处理文本。它提供了足够丰富的功能。事实上，文本是一个string对象，它可以被看作是一个字符序列，字符类型可能是char，或者wchar_t等等。string可以被转换成char*类型，这样便可以和以前所写的C/C++代码和平共处了。因为那时侯除了char*，没有别的。
国际化（internationalization）部分，作为OOP特性之一的封装机制在这里扮演着消除文化和地域差异的角色，采用locale和facet可以为程序提供众多国际化支持，包括对各种字符集的支持，日期和时间的表示，数值和货币的处理等等。毕竟，在中国和在美国，人们表示日期的习惯是不同的。
容器（containers）部分，STL的一个重要组成部分，涵盖了许多数据结构，比如前面曾经提到的链表，还有：vector（类似于大小可动态增加的数组）、queue（队列）、stack（堆栈）……。string也可以看作是一个容器，适用于容器的方法同样也适用于string。现在你可以轻松的完成数据结构课程的家庭作业了。
算法（algorithms）部分，STL的一个重要组成部分，包含了大约70个通用算法，用于操控各种容器，同时也可以操控内建数组。比如：find用于在容器中查找等于某个特定值的元素，for_each用于将某个函数应用到容器中的各个元素上，sort用于对容器中的元素排序。所有这些操作都是在保证执行效率的前提下进行的，所以，如果在你使用了这些算法之后程序变得效率底下，首先一定不要怀疑这些算法本身，仔细检查一下程序的其他地方。
迭代器（iterators）部分，STL的一个重要组成部分，如果没有迭代器的撮合，容器和算法便无法结合的如此完美。事实上，每个容器都有自己的迭代器，只有容器自己才知道如何访问自己的元素。它有点像指针，算法通过迭代器来定位和操控容器中的元素。
数值（numerics）部分，包含了一些数学运算功能，提供了复数运算的支持。
输入/输出（input/output）部分，就是经过模板化了的原有标准库中的iostream部分，它提供了对C++程序输入输出的基本支持。在功能上保持了与原有iostream的兼容，并且增加了异常处理的机制，并支持国际化（internationalization）。
总体上，在C++标准函数库中，STL主要包含了容器、算法、迭代器。string也可以算做是STL的一部分。
1.2 GP，GP和OOP
正如前面所提到的，在STL的背后蕴含着泛型化程序设计（GP）的思想，在这种思想里，大部分基本算法被抽象，被泛化，独立于与之对应的数据结构，用于以相同或相近的方式处理各种不同情形。这一思想和面向对象的程序设计思想（OOP）不尽相同，因为，在OOP中更注重的是对数据的抽象，即所谓抽象数据类型（Abstract Data Type），而算法则通常被附属于数据类型之中。几乎所有的事情都可以被看作类或者对象（即类的实例），通常，我们所看到的算法被作为成员函数（member function）包含在类（class）中，类和类则构成了错综复杂的继承体系。
尽管在象C++这样的程序设计语言中，你还可以用全局函数来表示算法，但是在类似于Java这样的纯面向对象的语言中，全局函数已经被"勒令禁止"了。因此，用Java来模拟GP思想是颇为困难的。如果你对前述的STL历史还有印象的话，应该记得Alexander Stepanove也曾用基于OOP的语言尝试过实现GP思想，但是效果并不好，包括没有引入模板之前的C++语言。站在巨人的肩膀上，我们可以得出这样的结论，在OOP中所体现的思想与GP的思想确实是相异的。C++并不是一种纯面向对象的程序设计语言，它的绝妙之处，就在于既满足了OOP，又成全了GP。对于后者，模板立下了汗马功劳。另外，需要指出的是，尽管GP和OOP有诸多不同，但这种不同还不至于到"水火不容"的地步。并且，在实际运用的时候，两者的结合使用往往可以使问题的解决更为有效。作为GP思想实例的STL本身便是一个很好的范例，如果没有继承，不知道STL会是什么样子，似乎没有人做过这样的试验。
1079
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
