VC工程项目配置

VC工程项目配置

一、VC包含目录、附加依赖项、库目录及具体设置

VS项目中的包含目录、库目录、附加包含目录、附加库目录、附加依赖项均在"项目->属性->配置属性"下进行配置，具体说明如下：

VC++目录：

包含目录：寻找#include中的xxxx.h的搜索目录

库目录：寻找.lib文件的搜索目录

C/C++：

常规->附加包含目录：寻找#include中的xxxx.h的搜索目录（每一项对应一个文件夹XXXX，文件夹中包含了编译时所需的头文件，使用时直接

#include即可）

链接器：

常规->附加库目录：寻找.lib文件的搜索目录

输入->附加依赖项：lib库（C++的库会把函数、类的声明放在*.h中，实现放在*.cpp或*.cc中。编译之后，*.cpp，*.cc，*.c会被打包成一个.lib文件，这样可以保护源代码）

常见问题：

1.包含目录和附加包含目录（库目录和附加库目录）的区别：

包含目录：修改了系统的include宏的值，是全局的；

附加包含目录：用于当前项目，对其他项目没有影响。

（库目录和附加库目录的区别同上）

2.可知包含目录和附加包含目录（库目录和附加库目录）的区别主要在于全局还是当前，那么当需要对某工程添加这些目录时，通常情况下，都是在附加包含目录和附加库目录中添加的。

3. 要使用一个库，除了要include其头文件以外（附加包含目录），还要在链接过程中把lib加进去（附加库目录、附加依赖项）。

4.添加方法：

附加包含目录---添加工程的头文件目录：

项目->属性->配置属性->C/C++->常规->附加包含目录：加上头文件的存放目录；

附加库目录---添加文件引用的lib静态库路径：

项目->属性->配置属性->链接器->常规->附加库目录：加上lib文件的存放目录；

附加依赖项---添加工程引用的lib文件名：

项目->属性->配置属性->链接器->输入->附加依赖项：加上lib文件名。

5.当需要向项目中添加.dll动态链接库时，直接将需要添加的.dll文件拖拽到项目生成的.exe所在的文件夹下即可（项目->属性->配置属性->常规->输出目录，可以看到.exe生成在哪个目录下）。

6.在添加上述几个目录的路径的时候，可以看到$(xxxx)，这就是宏了，可以点开右下角的宏查看这些分别代表什么字符串。

二、lib 和dll 的区别、生成以及使用详解

首先介绍一下静态库（静态链接库）、动态库（动态链接库）的概念，首先两者都是代码共享的方式。

静态库：在链接步骤中，连接器将从库文件取得所需的代码，复制到生成的可执行文件中，这种库称为静态库，其特点是可执行文件中包含了库代码的一份完整拷贝；缺点就是被多次使用就会有多份冗余拷贝。即静态库中的指令都全部被直接包含在最终生成的EXE 文件中了。在vs中新建生成静态库的工程，编译生成成功后，只产生一个.lib文件

动态库：动态链接库是一个包含可由多个程序同时使用的代码和数据的库，DLL不是可执行文件。动态链接提供了一种方法，使进程可以调用不属于其可执行代码的函数。函数的可执行代码位于一个DLL 中，该DLL 包含一个或多个已被编译、链接并与使用它们的进程分开存储的函数。在vs中新建生成动态库的工程，编译成功后，产生一个.lib文件和一个.dll 文件

那么上述静态库和动态库中的lib有什么区别呢？

静态库中的lib：该LIB包含函数代码本身（即包括函数的索引，也包括实现），在编译时直接将代码加入程序当中

动态库中的lib：该LIB包含了函数所在的DLL文件和文件中函数位置的信息（索引），函数实现代码由运行时加载在进程空间中的DLL提供

总之，lib是编译时用到的，dll是运行时用到的。如果要完成源代码的编译，只需要lib；如果要使动态链接的程序运行起来，只需要dll。

以下例子均在vs2010上测试

生成和使用动态库

生成动态库

新建项目--win32项目--填写项目名--确定--下一步--应用程序类型：选择dll--附加选项：选择导出符号--完成

可以看到生成了一个dllmain.cpp 文件，这是dll应用程序的入口，注意它和普通工程的入口main函数不同，这个文件我们不需要修改。

在这个动态库中我们举例导出一个变量，一个类，一个函数，头文件dll.h如下：

1//新建生成dll的工程时，vs默认定义了宏DLL_EXPORT,因此，DLL_API 是

__declspec(dllexport)，用来导出

2//当我们在静态调用dll时，我们包含该头文件，由于没有定义DLL_EXPORT，所以DLL_API 是

3//__declspec(dllimport),用来导入

4 #ifdef DLL_EXPORTS

5#define DLL_API __declspec(dllexport)

6#else

7#define DLL_API __declspec(dllimport)

8#endif

9

10// 导出类

11class DLL_API Cdll {

12public:

13Cdll(void);

14// TODO: 在此添加您的方法。

15 };

16

17//导出变量，变量在.cpp文件中定义

18extern DLL_API int ndll;

19

20//导出函数，加extern "C",是为了保证编译时生成的函数名不变，这样动态调用dll时才能

21//正确获取函数的地址

22extern"C" DLL_API int fndll(void);

dll.cpp 文件如下：

1 #include "dll.h"

2

3

4// 这是导出变量的一个示例

5 DLL_API int ndll=6;

6

7// 这是导出函数的一个示例。

8 DLL_API int fndll(void)

9 {

10return42;

11 }

12

13// 这是已导出类的构造函数。

14// 有关类定义的信息，请参阅dll.h

15Cdll::Cdll()

16 {

17return;

18 }

调用动态库

有两种方法调用动态库，一种隐式链接，一种显示链接。

调用动态库：隐式链接

隐式链接需要.h文件，dll文件，lib文件

（1）将dll放到工程的工作目录

（2）设置项目属性--vc++目录--库目录为lib所在的路径

（3）将lib添加到项目属性--链接器--输入--附加依赖项（或者直接在源代码中加入

#pragma comment(lib, “**.lib”)）

（4）在源文件中添加.h头文件

然后就像平常一样调用普通函数、类、变量

调用动态库：显示链接

显示链接只需要.dll文件，但是这种调用方式不能调用dll中的变量或者类（其实可以调用类，但是相当麻烦，有兴趣者可参考

https://www.360docs.net/doc/881481822.html,/jdcb2001/article/details/1394883）

显示调用主要使用WIN32 API函数LoadLibrary、GetProcAddress，举例如下：

1typedef int (*dllfun)(void);//定义指向dll中函数的函数指针

2 HINSTANCE hlib = LoadLibrary(".\\dll.dll");

3if(!hlib)

4 {

5std::cout<<"load dll error\n";

6return -1;

7 }

8dllfun fun = (dllfun)GetProcAddress(hlib,"fndll");

9if(!fun)

10 {

11std::cout<<"load fun error\n";

12return -1;

13 }

14fun();

生成和使用静态库

生成静态库

新建项目--win32项目--填写项目名--确定--下一步--应用程序类型：选择静态库静态库项目没有main函数，也没有像dll项目中的dllmain。

创建项目后添加.h文件，添加相应的导出函数、变量或类，如下所示

1 #ifndef _MYLIB_H_

2#define _MYLIB_H_

3

4void fun(int a);

5

6externint k;

7

8class testclass

9 {

10public:

11testclass();

12void print();

13 };

14

15#endif

.cpp文件如下

1 #include "stdafx.h"

2 #include "lib.h"

3 #include

4

5void fun(int a)

6 {

7std::cout<

8 }

9

10int k = 222;

11

12testclass::testclass()

13 {

14std::cout<<"123\n";

15 }

16

17void testclass::print()

18 {

19std::cout<<"this is testcalss\n";

20 }

编译工程后就会生成一个.lib文件

使用静态库

需要.h文件，lib文件

（1）设置项目属性--vc++目录--库目录为lib所在的路径

（2）将lib添加到项目属性--链接器--输入--附加依赖项（或者直接在源代码中加入#pragma comment(lib, “**.lib”)）

（3）在源文件中添加.h头文件

然后就像平常一样调用普通函数、类、变量，举例如下：

1 #include

2 #include "lib.h"

3

4#pragma comment(lib, "lib.lib")

5

6int main()

7 {

8fun(4);

9std::cout<

10testclasstc;

11tc.print();

12return0;

13 }

【版权声明】转载请注明出

处https://www.360docs.net/doc/881481822.html,/TenosDoIt/p/3203137.html

三、字符集设置

VC真是一个非常笨，非常不友好的工具，还是这样说，VC（MFC）和现在流行的。net framework java比起来就想石器时代跟工业时代相比一样！

接触MFC也有几年了，为了它有过加班、有过熬夜、甚至通宵，代码没有十万行也应该有几万行了。但是MFC就是这么牛，它牛得不但令新手忘而却步，而且常常令有经验的软件工程师也栽跟斗。最近由于一个小小的环境设置设置问题花了很多时间，这跟用惯了VC6

突然转到VC2005有关，但关键还是VC实在太笨了，它让我在一周内连续两中招次！

第一次中招是这样的，很简单：

我不知道https://www.360docs.net/doc/881481822.html,2005默认工程默认设置是采用“Unicode字符集”（Unicode Character Set）的，以前用VC6工程的时候默认是“多字符集”（Multi-Byte Character Set）的。以前也没有用过https://www.360docs.net/doc/881481822.html,2005啊，我一直认为。net是用来在framework上面编程的，在MFC 上编程没有必要打开庞大的。net2005，把机器弄得像牛拉车一样。

我声明了一个CString，按计划给它赋值，就像下面：

CString s；

s.Format（“count = %d”，count）；

按经验这肯定不会有错误的，但是不好意思，编译错误，因为这是我的环境采用的Unicode字符集的，而我给CString的Format函数是“多字符集”（Multi-Byte）所以编译不通过，要知道在这种设置下使用MessageBox（“ddd”）；编译是不会通过的，因为系统调用的是MessageBoxW，即Unicode宽字符集的那个函数。

还好我根据编译器的提示把s.Format（“count = %d”，count）；改成s.Format（_T （“count = %d”，count）；就搞定了，_T代表一个宏，宏的意思就是把字符串转成宽字符表示。同样的，MessageBox（“ddd”）；可以为MessageBox（_T（“ddd”））；

但是还有个问题就是，所有窗体显示的东西都是宽字符的，例如a在内存里就是a两个字节，前面一个字节a后面是，当从窗体取下数据（例如用户输入）要跟其他平台交互时，例如网络传输到远端机器。如果那边使用的不是Unicode字符集，就会出问题，为了使界面和后台传输一致，只好使用把宽字符转换成多字符集表示：

CStringstrWideChar;

strWideChar.Format(_T(“这是宽字节哦”));

char buf[20];

memset(buf,0,20);

WideCharToMultiByte( //转换Unicode到Ansi

CP_ACP,

WC_COMPOSITECHECK | WC_DEFAULTCHAR,

strWideChar,

strWideChar.GetLength(),

(char *)buf, //转换到缓冲区中

20, //最多个字节

0,

);

同样的，你接收到的字符串想要在界面正常显示，还必须把它转换成宽字节表示：

char chBytes[8];

memcpy(chBytes,”aaaaaaa”,8);

WCHAR wch[9];

n = MultiByteToWideChar( //转换Unicode到Ansi

CP_ACP,

0,

chBytes,

8,

wch, //转换到缓冲区中

8 //最多个字节

);

wch[n] = '';

这样每次从界面取数据和把数据显示到界面上都要先做处理，但是也可以把编译环境设置成“多字符集”（Multi-Byte Character Set），就可以避免这样转换来转换去（可惜我发现的时候代码已经差不多写完了）。就是在“Project->Configuration

Properties->General->Character Set，选择”Use Unicode Character Set“就是使用Uncode 字符集，选择” Use Multi-Byte Character Set“就是多字节字符集。

第二次中招，god，花了我好长时间才找到问题：

我在CodeProject上找了一个很厚道的老外写的一个继承了CDialog窗体类CResizableDialog的源码，这个类的作用是使MFC的窗体放大缩小时，窗体上的控件可以定位（Auchor），不要小看这个小小的每天都要用到的功能，用MFC实现真的很麻烦。很佩服那个老外写了那么多代码（当然跟他们的条件有关，资本主义国家的工人随便找个工作就可以衣食无忧，病了政府照顾，我们做“挨踢”的活得像民工一样，当然没有那个闲情去写那么好的代码免费给别人使用，这是题外话）。

我拿了那个现成的工程，直接在我的工程里引用他的工程。Everything works perfect.直到我把项目发布成Release的，双击运行后没有任何反应，Very weird！后来我用MessageBox打印消息，发现运行到DoModal函数里面就没有出来，程序直接退出了！使用try，catch都得不到错误！因为我的窗体是继承老外写的窗体类来的，原先继承CDialog 是好好的，问题肯定在他的工程里面，可是他给的示例程序没有任何问题啊。MFC出错的时候是很要命的，它不会给你任何提示，它就是不干了！

我又拿一个前的测试程序，让它从CResizableDialog继承，也没有任何问题。

简直头大了、无语了，不知道哪里出现了问题，Release又不能像Debug那样调试，打了一堆MessageBox后还是不知道问题出现在哪里。凭着经验，可以知道程序中可能出现了内存的越界访问什么的致命错误，才会导致程序“一声不吭”地退出，但是究竟哪里出了问题呢？

就在束手无策的时候，我发现调用CResizableDialog的成员函数EnableSaveRestore 会引发链接错误：“未定义的外部符号”，不引用它不会出错，测试程序引用它没有任何错误。通常这个错误造成是因为引用函数在。h文件里声明了，但是在。cpp里面没有定义，或者。cpp文件里的定义和。h上的参数对不上。但是此时不可能是这个错误，因为测试程序没有错误啊。直觉告诉我这是解决“Release后程序直接退出的关键”，说不定这个函数调用的问题解决了Release的问题也解决了。

MFC真是很强大，它强大得不但“像迷宫一样，里面有怪兽，进去一不小心就永远出不来”，而且它让你当遇到怪兽的时候总是给你一点点星光，只要你不放弃，奇迹就会出现，你就会练成绝世神功。这跟武侠小说是相通的，主人公每次到了生死关头就会出现奇迹，成为天下无敌的高手。看看我怎么找到解决方法的，Very tricky。

既然调用EnableSaveRestore出现了不该出现的错误，那么就从这个函数开始找。这个函数是这样的：

.h文件声明

void EnableSaveRestore(LPCTSTR pszSection, BOOL bRectOnly = FALSE);

.cpp文件定义

void CResizableDialog::EnableSaveRestore(LPCTSTR pszSection, BOOL bRectOnly/* = FALSE */)

{

m_sSection = pszSection;

m_bEnableSaveRestore = TRUE;

m_bRectOnly = bRectOnly;

// restore immediately

LoadWindowRect(pszSection, bRectOnly);

}

上面的代码没有任何错误，既然没有错误，就要用使用以下方法来找：

1.重新为CResizableDialog写一个函数，它没有参数的，调用它，发现没有错误，看来参数有问题。

2.既然没有参数的函数没有错误，就把出问题的函数参数去掉吧，竟然也没有错误！那问题就肯定是出在参数上。

3.去掉其中一个参数，测试发现是LPCTSTR pszSection的问题，而不是BOOL bRectOnly 的问题。

4.既然这样，那就换一种表示吧，把LPCTSTR pszSection换成WCHAR* pszSection，运行它，竟然不出错了！翻开MFC宏定义，就会发现其实LPCTSTR和WCHAR*是一样的，MFC 真是freak！

5.但是这个函数功能还是不正常，断点进入那个函数里面发现传进去的字符串只有一个字符了，这种情况就是宽字符当成短字符时，第二个字节的当成了字符串的截止字符了，也就是说，这个函数里采用的是短字符（多字符集Multi Byte）处理的。

6.我的工程采用的是宽字符集（Unicode Char）的，检查设置，原来那个老外是用VC6编的，默认是使用多字符集（Multi Byte）的，VC真是笨啊，两个Project在一个Solution 里面完全不同的设置竟然没有任何提示，简直把我弄死了！

7.把引用工程也改成使用Unicode字符集，并且把函数EnableSaveRestore WCHAR* pszSection恢复原样，搞定！果然不出我所料，Release也没有问题了！我用以前的那个测试程序来使刚好以前把它设成Multi Byte，所以也没有错误，Damn！

仅仅是一个设置啊，如果VC出错提示稍微好的，至少字符集不匹配不要说成“未定义的外部符号”也好用一点啊，难怪现在用VC的人越来越少了！

注：通常说的VC不是指使用。net framework的VC，那个很简单，内存都不用管，通常是指非托管的VC。