引用C++primer的话：C++支持两种模板编译模式包含模式(Inclusion Model )和分离模式(Separation Model)
1. 包含编译模式
在包含编译模式下，在每个模板被实例化的文件中包含函数模板的定义并且往往把定义放在头文件中像对内联函数所做的那样。
2. 分离编译模式
在分离编译模式下函数模板的声明被放在头文件中 , 在模板定义中有一个关键字export, 关键字export 告诉编译器在生成被其他文件使用的函数模板实例时可能需要这个模板定义编译器必须保证在生成这些实例时该模板定义是可见的 , 关键字export 不需要出现在头文件的模板声明中, 分离模式使我们能够很好地将函数模板的接口同其实现分开进而组织好程序以便把函数模板的接口放到头文件中而把实现放在文本文件中, 但是并不是所有的编译器都支持分离模式, 即使支持也未必总能支持得很好, 支持分离模式需要更复杂的程序设计环境所以它们不能在所有C++编译器实现中提供。
3. 详细说明
大部分编译器在编译模板时都使用包含模式，也就是一般使用时把模板放到头文件中在包含。当你不使用这个模版函数或模版类,编译器并不实例化它 ,当你使用时，编译器需要实例化它，
因为编译器是一次只能处理一个编译单元, 也就是一次处理一个cpp文件,所以实例化时需要看到该模板的完整定义
，所以都放在头文件中。这不同于普通的函数, 在使用普通的函数时，编译时只需看到该函数的声明即可编译, 而在链接时由链接器来确定该函数的实体。
4.举例说明
//test.h
template<class T>
class Test()
public:
mFun();
private:
T value;
____________________________
//test.cpp
#include"test.h"
void Test<T>::mFun()
_____________________________
//main.cpp
#include"test.h"
int main()
Test<int> m_test;
m_test.mFun();//#1
return 0;
编译器在#1处并不知道Test<int>::mFun的定义，因为它不在test.h里面，于是编译器只好寄希望于连接器，希望它能够在其他.obj里面找到Test<int>::mFun的实例，在本例中就是test.obj，然而，后者中真有Test<int>::mFun的二进制代码吗？NO！！！因为C++标准明确表示，当一个模板不被用到的时侯它就不该被实例化出来，test.cpp中用到了Test<int>::mFun了吗？没有！！所以实际上test.cpp编译出来的test.obj文件中关于Test::mFun一行二进制代码也没有，于是连接器就傻眼了，只好给出一个连接错误。但是，如果在test.cpp中写一个函数，其中调用Test<int>::mFun，则编译器会将其实例化出来，因为在这个点上（test.cpp中），编译器知道模板的定义，所以能够实例化，于是，test.obj的符号导出表中就有了Test<int>::mFun这个符号的地址，于是连接器就能够完成任务。
在STM32F103C8T6标准库中，可以使用printf函数输出调试信息，但默认情况下，printf函数输出到串口，需要使用串口调试助手等工具查看输出结果。如果想要将printf函数的输出重定向到其他设备或接口，可以使用重定向函数。以下是步骤：
1. 在main函数中添加以下代码，将printf函数重定向到自定义的函数中：
#include <stdio.h>
#include <stdarg.h>
int fputc(int ch, FILE* stream)
// 将ch输出到你想要的设备或接口
return ch;
2. 在main函数中使用以下代码，将stdout流重定向到上述的fputc函数：
int main(void)
// 其他初始化代码
// ...
// 重定向stdout流到fputc函数
stdout->_write = fputc;
// 其他代码
// ...
3. 现在，当你在代码中使用printf函数时，输出将被重定向到fputc函数，你可以在fputc函数中将其输出到你想
为何DLL
先看看静态库与DLL的不同之处
可执行文件的生成（Link期）：前者很慢（因为要将库中的所有符号定义Link到EXE文件中），而后者很快（因为后者被Link的引入库文件无符号定义）
可执行文件的大小：前者很大，后者很小（加上DLL的大小就和前者差不多了）
可执行文件的运行速度：前者快（直接在EXE模块的内存中查找符号），后者慢（需要在DLL模块的内存中查找，在另一个模块的内存中查找自然较慢）
可共享性：前者不可共享，也就是说如果两个EXE使用了同一个静态库，那么实际在内存中存在此库的两份拷贝，而后者是可共享的。
可升级性：前者不可升级（因为静态库符号已经编入EXE中，要升级则EXE也需要重新编译），后者可以升级（只要接口不变，DLL即可被升级为不同的实现）
综合以上，选择静态库还是DLL
1. 静态库适于稳定的代码，而动态库则适于经常更改代码（当然接口要保持不变），当DLL更改（仅实现部分）后，用户不需要重编工程，只需要使用新的Dll即可。
2. 由于静态库很吃可执行文件的生成（Link期）时间，所以如果对可执行文件的Link时间比较敏感，那么就用DLL。
使用DLL
在介绍如何创建DLL之前，让我们先了解它是如何被使用的。
1. 显式调用（也叫动态调用）
显 示调用使用API函数LoadLibrary或者MFC提供的AfxLoadLibrary将DLL加载到内存，再用GetProcAddress()在 内存中获取引入函数地址，然后你就可以象使用本地函数一样来调用此引入函数了。在应用程序退出之前，应该用FreeLibrary或MFC提供的 AfxLoadLibrary释放DLL。
下面是个显示调用的例子，假定你已经有一个Test.dll，并且DLL中有个函数名为Test，其声明式是void();
#include < iostream >
using namespace std;
typedef void(*TEST )();
int main( char argc, char* argv[] ) {
const char* dllName = "Test.dll";
const char* funcName = "Test";
HMODULE hDLL = LoadLibrary( dllName );
if ( hDLL != NULL ) {
TEST func = TEST( GetProcAddress( hDLL, funcName ) );
if ( func != NULL ) {
func();
else {
cout << "Unable to find function \'" << funcName << "\' !" << endl;
FreeLibrary( hDLL );
else {
cout << "Unable to load DLL \'" << dllName << "\' !" << endl;
return 0;
1. 显示调用使用GetProcAddress，所以只能加载函数，无法加载变量和类。
2. 此外GetProcAddress是直接在.dll文件中寻找同名函数，如果DLL中的Test函数是个C++函数，那么由于在.dll文件中的实际文件名会被修饰（具体被修饰的规则可参考函数调用约定详解或者使用VC自带的Depends.exe查看），所以直接找Test是找不到的，这时必须把函数名修改为正确的被修饰后的名称，下面是一种可能（此函数在DLL中的调用约定为__cdecl）：
const char* funcName = "?Test@@YAXXZ";
2. 隐式调用（也叫静态调用）
隐式调用必须提供DLL的头文件和引入库（可以看作轻量级的静态库（没有符号定义，但是说明了符号处于哪个DLL中））。
有了头文件和引入库，DLL的使用就跟普通静态库的使用没啥区别，只除了DLL要和EXE一起发布。
显示调用与隐式调用的优缺点
显示调用使用复杂，但能更加有效地使用内存，因为DLL是在EXE运行时（run time）加载，必须由用户使用LoadLibrary和FreeLibrary来控制DLL从内存加载或卸载的时机。此外还可以加载其他语言编写的DLL函数。
静态调用使用简单，但不能控制DLL加载时机，EXE加载到内存同时自动加载DLL到内存，EXE退出时DLL也被卸载。
创建DLL
下面我们着重讲解如何在VC下创建DLL
首先要建立一个Win32的DLL工程。再把普通静态库的所有文件转移到DLL工程中，然后：
为所有的类声明加上__declspec(dllexport)关键字，这有这样编译器才能自动为你产生引入库文件（否则你需要自己写.def文件来产生，因为不常用所以在此不再阐述其细节）
对于DLL的用户来讲，类声明就需要用另外一个关键字__declspec(dllimport)（此关键字对于类和函数而言并非必须，但对于变量而言则是必须的）。所以通常我们会定义一个宏来包装之，比如
#ifdef MYDLL_EXPORTS
# define MYDLL_API __declspec(dllexport)
#else
# define MYDLL_API __declspec(dllimport)
#endif
这样我们就能写出如下的类
class MYDLL_API MyClass {
当然在创建DLL的工程里需要包含preprocessor(预处理指示器)MYDLL_EXPORTS，而在用户工程里面则不应该包含MYDLL_EXPORTS。
其实上面说的VC早就帮我们做好了。如果你创建的DLL工程叫做Test，那么此工程自动包含TEST_EXPORTS。如果你在创建工程的时候选择了Exprot Symbols, 那么VC还会自动帮你创建一个示例文件Test.h，此文件定义出
#ifdef TEST_EXPORTS
# define TEST_API __declspec(dllexport)
#else
# define TEST_API __declspec(dllimport)
#endif
你自定义的文件都应该包含此文件以使用TEST_API。（如果没有选择Exprot Symbols，那么就得自己动手写出这段宏了）
示例文件中还包括了一个类，变量，以及全局函数的写法
class TEST_API CTest {
public:
CTest(void);
// TODO: add your methods here.
extern TEST_API int nTest;
TEST_API int fnTest(void);
通过上面的示例我们也可以看出全局(或者名字空间)变量和函数的声明方法
1. DLL的入口函数DllMain并非必须，如果没有它，编译器会帮你自动生成一个不做任何事的DllMain。
2. 如果是可以定义在头文件里面的东西：包括宏，常量，内联函数（包括成员内联函数）以及模板。那么在DLL中的定义中可以不必包含TEST_API，和普通的定义没有区别。
如果一个类完全由内联函数和纯虚函数构成，那么也不需要TEST_API这样的关键字。一个不带成员函数的struct也一样。
3. 所有未经__declspec(dllexport)导出的类都只能作为DLL内部类使用。当然外部仍然可以使用其内联成员函数（前提是该成员函数不应该调用任何未经导出的函数或者类成员函数）
发布DLL
1. 程序库的作者应该将三件套：头文件，引入库文件和DLL一同发布给用户，其中头文件和引入库是专为静态调用的用户准备，也就是C/C++用户。（此外有些 DLL内部使用的头文件，如果没有被接口头文件直接#include，那么该头文件就不必发布，这和静态库是一样的）。
2. DLL的用户只需将DLL和可执行程序一同发布即可。
C++程序使用C语言DLL（静态库规则一样）
C不存在class, 所以由C创建的DLL必然也不会出现class；对于全局变量的使用C和C++没有什么不同，所以我们把焦点集中在全局函数上（此外全局变量的规则一样）。
我们知道C++程序要使用C语言的函数就必须在函数声明前加上extern "C"关键字，这对于静态库和DLL没有什么不同。 但是这个关键字不能直接出现在头文件函数声明中，否则DLL无法通过编译， 原因很简单，C语言并没有extern "C"这个关键字。
1. 一种作法是把C向C++迁移的责任交给DLL创建者。定义出一个宏，以使DLL（C工程）中不出现extern "C"或者只是extern，而在用户工程（C++工程）中保持原样。幸运的是windows早已为我们设计好一切，这个宏就是EXTERN_C（存在于 winnt.h中） :
#ifdef __cplusplus
#define EXTERN_C extern "C"
#else
#define EXTERN_C extern
#endif
注意上面必须是extern而不是空。因为虽然C的函数声明不是必须添加extern，但是变量声明则必须添加extern。
有了EXTERN_C，在头文件中这样定义函数：
EXTERN_C TEST_API int fnTest(void);
2. 另外一种做法是把把C向C++迁移的责任交给用户，用户在包含DLL头文件的时候以extern "C"来include:
extern "C" {
#include "mydll.h"
#include "mydllcore.h"
可以把上述的extern "C"段放在新的头文件中和DLL一起发布，这样C++用户只需要包含这个头文件就可以了。比如Lua库就自带了一个etc/lua.hpp文件。通常此文件会由DLL作者提供，所以此时迁移的责任仍在DLL创建者。
注意用户不要试图以extern "C"来重新声明函数，因为重复声明是允许的，但是必须保证和头文件中的声明相同。
3. 这种做法的一个变形就是直接在C头文件中以extern "C"将所有函数和变量声明包含之，这样就无需像上面那样多提供一个额外的头文件了。通常像这样（mydll头文件）：
#include 头文件段
#ifdef __cplusplus
extern "C" {
#endif
函数和变量声明
#ifdef __cplusplus
#endif
创建标准的DLL，使其可被其他语言使用
通常我们会希望DLL能够被其他语言使用，因而我们的DLL往往不会提供类定义，而只提供函数定义。（因为许多编程语言是不支持类的）。
此时函数的调用约定必须是__stdcall（在vc下默认是__cdecl，所以你不得不手工添置），因为大部分语言不支持__cdecl，但支持__stdcall（比如VBScript，Delphi等）。
此外我们希望导出到DLL中的函数名能够更易被识别（用户使用才会更方便），也就是说DLL应该编译出无修饰的C函数名。
所以我们可能会
1. 如果你只用C语言，那么必然以C文件创建DLL（自动编出C符号名），考虑到潜在的C++用户（此类用户多以静态调用方式使用DLL，因而需要看到其函数声明），我们还需要使用EXTERN_C关键字（详见上面的讨论）。
2. 如果你使用C++，那么必然以C++文件创建DLL，这时你应该直接以extern "C"修饰。
所以要创建能够为任意编程语言使用之DLL，我们应该
1. 只创建函数
2. 声明__stdcall调用约定（或者WINAPI，CALLBACK，前提是你必须包含windows头文件）
3. 以CPP文件 + extern "C" 或者 C文件 + EXTERN_C
4. 当然还需要DLL_API的声明（如果光有dllexport,那么DLL也只能被显示调用）。
更完美一点
不应该使用dllexport和extern "C"而应该使用.def文件。虽然经过上面的4个步骤，我们的DLL里面的C函数名已经相当简洁了，但仍不是最完美的：比如一个声明为function的函数，实际在DLL中的名字确可能是function@#。而使用.def文件，我们可以让DLL中的函数名和声明的函数名保持一致。
关于.def的详细用法可参考：
微软DLL专题
使用 DEF 文件从 DLL 导出
在DLL与静态库之间切换
前面我曾经提到对于使用DLL的用户__declspec(dllimport)关键字可有可无，当然前提是DLL中不包括变量定义。
所以要把库既能够做成DLL，也能够做成静态库，那么就应该作出类似下面这样的定义：
1. DLL不包括变量的定义
#ifdef TEST_EXPORTS
# define TEST_API __declspec(dllexport)
#else
# define TEST_API
#endif
然 后只要把工程的配置属性（Configuration Type）简单地在Static Library (.lib)或者Dynamic Library (.dll)切换即可（VC会自动地为DLL添加预处理器TEST_EXPORTS，为静态库取消TEST_EXPORTS）。
2. DLL包含变量定义，也是标准的做法
#ifdef TEST_BUILD_AS_DLL
#ifdef TEST_EXPORTS
# define TEST_API __declspec(dllexport)
#else
# define TEST_API __declspec(dllimport)
#endif
#else
#define TEST_API
#endif
如果要将库做成DLL，那么需要DLL创建者添加预处理器TEST_BUILD_AS_DLL和TEST_EXPORTS，后者通常由编译器自动添加；如果做成静态库则不需要添加任何预处理器。
用户则可以通过添加或取消TEST_BUILD_AS_DLL来使用动态库或静态库。
对于DLL的用户，TEST_BUILD_AS_DLL这个名称似乎起得不好。下面的做法或许会更合理些：
#if defined(TEST_API)
#error "macro alreday defined!"
#endif
#if defined(TEST_BUILD_DLL) && defined(TEST_USE_DLL)
#error "macro conflict!"
#endif
#if defined(TEST_BUILD_DLL) // build dll
# define TEST_API __declspec(dllexport)
#elif defined(TEST_USE_DLL) // use dll
# define TEST_API __declspec(dllimport)
#else // build or use library, no preprocessor needs
# define TEST_API
#endif
微软DLL专题
Windows API编程之动态链接库（DLL）
这是程序使用的所有 Microsoft Windows 资源的列
表。它包含存储在RES子目录中的图标、位图和光标。
可直接在 Microsoft Visual C++ 中编辑此文件。项
目资源包含在 2052 中。
res\modifyfile.ico
这是一个图标文件，用作应用程序的图标。此图标包
含在主资源文件 modifyfile.rc 中。
res\modifyfile.rc2
此文件包含不由 Microsoft Visual C++ 编辑的资源。
应将所有不能由资源编辑器编辑的资源放在此文件中。
////////////////////////////////////////////////////
应用程序向导将创建一个对话框类：
modifyfileDlg.h、modifyfileDlg.cpp - 对话框
这些文件包含 CmodifyfileDlg 类。此类定义应用程
序主对话框的行为。此对话框的模板包含在 modifyfile.rc
中，而此文件可以在 Microsoft Visual C++ 中进行编辑。
////////////////////////////////////////////////////
其他功能：
ActiveX 控件
应用程序支持使用 ActiveX 控件。
打印支持和打印预览支持
应用程序向导已生成了一些代码，通过从 MFC 库调用
CView 类中的成员函数来处理打印、 打印设置和打印
预览命令。
////////////////////////////////////////////////////
其他标准文件：
StdAfx.h、StdAfx.cpp
这些文件用于生成名为 modifyfile.pch 的预编译头
文件 (PCH)和名为 StdAfx.obj 的预编译类型文件。
Resource.h
问题：某个头文件中声明并定义了一个函数，然后在多个源码文件中调用该函数，编译链接时出现了该函数multiple definition问题，在头文件中添加了 #ifndef 头也不行，经过尝试发现如果将该函数的声明和定义分开到.h和.cpp文件之后问题消失，为什么不能将函数直接定义在.h文件中呢？
针对该问题，抽象出如下几个问题：
1头文件中只可放置函数声明，不可放置函数定义吗？
以下面的程序为例：
// a.h
#ifndef __a_h__
#define __a_h__
void funcA(void)
C++内联函数
内联函数的实现方法就是在普通函数定义处增加inline关键字，为的是消除函数调用的时空开销，是C++提供的一种提高效率的方法，即在编译时将函数调用处用函数体替换，类似于C语言中的宏展开。
inline关键字要出现在函数定义处，在函数声明处增加了inline也是会被编译器忽略掉的。
在C++实际开发中一般只将那些短小的、频繁调用的函数定义为内联函数。
在多文件编程中，通常情况下普通函...
解决方法：将模板函数的声明和定义都放在.h文件中。（不讲武德）
粗浅分析：我们不将普通函数的定义放在.h文件中，就是怕在多个.cpp文件都用到该.h文件，造成多重定义。而对于模板，在实例化模板之前，编译器对模板的定义体是不处理的。所以就没有了会出现多重定义的顾虑。而在进行实例化模板函数，要求编译器在实例化模板时必须在上下文中可以查看到其定义实体。
参考文章：
对于所有的喜欢把声明和定义分开放的C++er，在写模板时要把它俩放在一起一定感到十分郁闷，于是我本着非要棒打鸳鸯的倾向，找到了几种“棒”~
欢迎各位完善棒打鸳鸯技巧~
1.在模板的声明文件（.h）的最后一行
#include ".cpp" //模板的实现文件
2.在调用模板的文件在文件开头
#include ".cpp" //模板的实现文件
资源编辑器编辑的资源放在此文件中。
/////////////////////////////////////////////////////////////////////////////
应用程序向导将创建一个对话框类：
ScreenCaptureDlg.h、ScreenCaptureDlg.cpp - 对话框
这些文件包含 CScreenCaptureDlg 类。 此类定义
应用程序主对话框的行为。 此对话框的模板包含在
ScreenCapture.rc 中，而此文件可以在 Microsoft Visual C++ 中进行编辑。
/////////////////////////////////////////////////////////////////////////////
其他功能：
ActiveX 控件
应用程序支持使用 ActiveX 控件。
打印支持和打印预览支持
应用程序向导已生成了一些代码，通过从 MFC 库调用 CView 类中的成员函数来
处理打印、打印设置和打印预览命令。
/////////////////////////////////////////////////////////////////////////////
其他标准文件：
StdAfx.h、StdAfx.cpp
这些文件用于生成名为 ScreenCapture.pch 的预编译头文件 (PCH)
和名为 StdAfx.obj 的预编译类型文件。
Resource.h
这是标准头文件，它定义新资源 ID。
Microsoft Visual C++ 将读取并更新此文件。
/////////////////////////////////////////////////////////////////////////////
其他说明：
应用程序向导使用“TODO:” 来指示
应添加或自定义的源代码部分。
如果应用程序在共享 DLL 中使用 MFC，且应用程序使用的语言不是
操作系统的当前语言，则需要从 Microsoft Visual C++ 光盘上
Win\System 目录下将相应的本地化资源 MFC70XXX.DLL
复制到计算机的 system 或 system32 目录下，
并将其重命名为 MFCLOC.DLL。 （“XXX”代表
语言缩写。 例如，MFC70DEU.DLL 包含翻译成
德语的资源。） 如果不这样做，应用程序的某些 UI 元素
将保留为操作系统的语言。
1.问题描述
密码学分为两类密码：对称密码和非对称密码。对称密码主要用于数据的加/解密，而非对称密码则主要用于认证、数字签名等场合。非对称密码在加密和解密时，是把加密的数据当作一个大的正整数来处理，这样就涉及到大整数的加、减、乘、除和指数运算等，同时，还需要对大整数进行输出。请采用相应的数据结构实现大整数的加、减、乘、除和指数运算，以及大整数的输入和输出。
2.实验基本要求
要求采用链表来实现大整数的存储和运算，不允许使用标准模板类的链表类(list)和函数。同时要求可以从键盘输入大整数，也可以文件输入大整数，大整数可以输出至显示器，也可以输出至文件。大整数的存储、运算和显示，可以同时支持二进制和十进制，但至少要支持十进制。大整数输出显示时，必须能清楚地表达出整数的位数。测试时，各种情况都需要测试，并附上测试截图；要求测试例子要比较详尽，各种极限情况也要考虑到，测试的输出信息要详细易懂，表明各个功能的执行正确；
1. 要求大整数的长度可以不受限制，即大整数的十进制位数不受限制，可以为十几位的整数，也可以为500多位的整数，甚至更长；大整数的运算和显示时，只需要考虑正的大整数。如果可能的话，请以秒为单位显示每次大整数运算的时间；
2. 要求采用类的设计思路，不允许出现类以外的函数定义，但允许友元函数。主函数中只能出现类的成员函数的调用，不允许出现对其它函数的调用。
3. 要求采用多文件方式：.h文件存储类的声明，.cpp文件存储类的实现，主函数main存储在另外一个单独的cpp文件中。如果采用类模板，则类的声明和实现都放在.h文件中。
4. 不强制要求采用类模板，也不要求采用可视化窗口；要求源程序中有相应注释；
5. 要求采用Visual C++ 6.0及以上版本进行调试；
3.实现提示
1. 大整数的加减运算可以分解为普通整数的运算来实现；而大整数的乘、除和指数运算，可以分解为大整数的加减运算。
2. 大整数的加、减、乘、除和指数运算，一般是在求两大整数在取余操作下的加、减、乘、除和指数运算，即分别求 (a +b) mod n, (a - b) mod n, (a * b) mod n, (a / b) mod n 和(a ^ b) mod n。其中a ^ b 是求a的b次方，而n称之为模数。说明：取余操作(即mod操作)是计算相除之后所得的余数，不同于除法运算的是，取余操作得到的是余数，而不是除数。如7 mod 5 = 2。模数n的设定，可以为2m 或10m，m允许每次计算时从键盘输入。模数n的取值一般为2512(相当于十进制150位左右),21024(相当于十进制200~300位),22048(相当于十进制300~500位)。为了测试，模数n也可以为2256, 2128等值。
3. 需要设计主要类有：链表类和大整数类。链表类用于处理链表的相关操作，包括缺省构造函数、拷贝构造函数、赋值函数、析构函数、链表的创建、插入、删除和显示等；而大整数类则用于处理大整数的各种运算和显示等。
模板定义很特殊。由template<…> 处理的任何东西都意味着编译器在当时不为它分配存储空间，它一直处于等待状态直到被一个模板实例告知。在编译器和连接器的某一处，有一机制能去掉指定模板的多重定义。所以为了容易使用，几乎总是在头文件中放置全部的模板声明和定义。
"对C++编译器而言，当调用函数的时候，编译器只...
本文，仅针对模板函数的写的位置做讨论（记录）。
首先，c++的模板是要有调用，才会被编译的。 因为本身函数要被编译成具体的参数，函数名，返回值类型的一条函数记录（个人理解），记录在函数表中， 而模板本身就是一个泛型， 只有被调用的时候才会产生一个具体的函数记录。 比如
template
Class TestC
Public:
