文章地址
工程结构
External Dependencies
工程的外部依赖文件，这个目录是VS自动生成的，你最好别动它。
Header Files
头文件，也就是.h(.hpp)后缀的头文件。
Source Files
源文件，也就.cpp(或.c，针对C语言)后缀的文件。
Resource Files
资源文件，如果你创建的是MFC的工程，*.rc文件就会在这里。
VA助手快捷键
Alt+G 快速跳转，如由声明跳转到实现，由实现跳转到声明。 光标要在标识符处
Alt+O .h与.cpp文件的快速切换
Alt+Shift+F 查找标识符所有被引用的位置 光标要在标识符处
Alt+Shift+O 查找整个Solution下的某个文件 O指open，打开指定的文件
Alt+Shift+S 查找标识符 S指Symbol
Alt+Shift+R 重命名标识符 光标要在标识符处,R指ReName
Ctrl+Shift+V 选择剪切板的内容进行粘贴
SVN
VisualSVN是一个VS插件，依赖于SVN，使用插件的话，同时也要按照SVN。
VisualSVN的官方下载地址
SVN的官方下载地址
需要上传的文件类型
h: 头文件
cpp: 源文件
txt: 说明文件，如readme
rc: 资源文件
rc2: 资源文件
ico: 图标，如logo等
sln: 解决方案工程文件
vcxproj: 工程文件
filters: 文件过虑器
不要上传的文件类型
Debug、Release等编译结构目录
ipch目录
aps: last resource editor state
exe: build result
idb: build state
ipch: build helper
lastbuildstate: build helper
lib: build result. Can be 3rd party
log: build log
manifest: build helper. Can be written yourself.
obj: build helper
pch: build helper
pdb: build result
res: build helper
sdf: intellisense dbase
suo: solution user options
tlog: build log
user: debug settings. Do preserve if just one dev or custom debug settings
预编译头
如果你的工程选用了预编译头文件的方式，每一个.cpp文件的第一行代码必须包含预编译头文件(#include “stdafx.h”)，否则会编译出错。
预编译技术的内存原理
在Windows程序开发时，经常要在各个文件中包含windows.h、afx.h等标准头文件，而这些文件非常的大，在编译时就非常的慢，非常耗时。为解决这个问题，已是就有了预编译头文件的技术。
所谓头文件预编译技术，就是把一个工程(Project)中常用的一些头文件(如标准头文件Windows.h、Afxwin.h等，也可以是自己定义的头文件)包含在stdafx.h中，并对stdafx.h预先编译(在所有的.cpp文件编译之前进行编译)，得到编译结果.pch文件(默认名称为ProjectName.pch)，后期该工程在编译其它.cpp文件时不再编译stdafx.h中的内容(即使include了它)，仅仅使用预编译的结果。
其中stdafx.h叫做预编译头文件，stdafx名称的英文全称为：Standard Application Framework Extensions，当然你也可以自己定义预编译头文件的名称，手动重命名stdafx.h，同时将上面图2和图3中对应的名称也得改过来。ProjectName.pch叫做预编译头。
采用预编译头技术后，可以加快编译速度，节省编译时间。因为只需要预先编译一次就可以在所有的.cpp编译时使用，不用再次编译。这样带来的一个问题就是每一个.cpp文件的开头都要包含预编译头文件#include “stdafx.h”。因为预编译头技术是假定预编译头中的内容会在所有.cpp文件中使用，在编译你的 .cpp 的时候，就会将预编译头中已经编译完的部分加载到内存中。
使用预编译头文件需要注意的几个要点：
- 你编写的任何.cpp文件都必须首先包含stdafx.h。
- 如果你有工程文件里的大多数.cpp文件需要的.h文件，顺便将它们加在stdafx.h(后部)上，然后预编译stdafx.cpp。
- 由于.pch文件具有大量的符号信息，它是你的工程文件里最大的文件。
非MFC工程中使用MFC库
貌似会很有用，现存起来，以后用到再说。
非MFC工程中使用MFC库
Runtime Library
单线程库
多线程是必要的，单线程的两个库早就弃用了。
多线程lib库
一个解决方案可能包含多个项目，如果每个项目都使用lib运行库，那么会冲突。
项目也会依赖项目，这两个项目如果都使用lib运行库，那么也会冲突。
结论
Release和Debug分别使用：MD（多线程DLL库）和MDd（Debug多线程DLL库），其他的都不用。
多字节编码与Unicode码
1.Character Set
Configuration Properties -> General -> Character Set
当设置为Use Unicode Character Set时，会有预编译宏：_UNICODE、UNICODE
当设置为Use Multi-Byte Character Set时，会有预编译宏：_MBCS
2. 不同Character Set，参数类型不同
WINUSERAPI
int
WINAPI
MessageBoxA(
__in_opt HWND hWnd,
__in_opt LPCSTR lpText,
__in_opt LPCSTR lpCaption,
__in UINT uType);
WINUSERAPI
int
WINAPI
MessageBoxW(
__in_opt HWND hWnd,
__in_opt LPCWSTR lpText,
__in_opt LPCWSTR lpCaption,
__in UINT uType);
#ifdef UNICODE
#define MessageBox MessageBoxW
#else
#define MessageBox MessageBoxA
#endif // !UNICODE
| 类型 | MBCS | UNICODE |
|---|---|---|
| WCHAR | wchar_t | wchar_t |
| LPSTR | char* | char* |
| LPCSTR | const char* | const char* |
| LPWSTR | wchar_t* | wchar_t* |
| LPCWSTR | const wchar_t* | const wchar_t* |
| TCHAR | char | wchar_t |
| LPTSTR | TCHAR(或char) | TCHAR* (或wchar_t*) |
| LPCTSTR | const TCHAR* | const TCHAR* |
3.不同Character Set，编码方式不同
上面的Multi-Byte Character Set一般是指ANSI（多字节）字符集。而Unicode Character Set就是Unicode字符集，一般是指UTF-16编码的Unicode。也就是说每个字符编码为两个字节，两个字节可以表示65535个字符，65535个字符可以表示世界上大部分的语言。
一般推荐使用Unicode的方式，因为它可以适应各个国家语言，在进行软件国际时将会非常便得。除非在对存储要求非常高的时候，或要兼容C的代码时，我们才会使用多字节的方式 。
4.在C++代码中定义不同编码方式的字符串
- 用常量字符给wchar_t变量赋值时，前面要加L。如： wchar_t wch2 = L’中’;
- 用常量字符串给wchar_t数组赋值时,前面要加L。如： wchar_t wstr2[3] = L”中国”;
- 如果不加L，对于英文可以正常，但对于非英文(如中文)会出错。
5.理解_T()、_Text()宏即L”“
查看tchar.h头文件的定义我们知道_T和_TEXT的功能是一样的，是一个预定义的宏。
#define _T(x) __T(x)
#define _TEXT(x) __T(x)
再看看__T(x)的定义，发现它有两个：
#ifdef _UNICODE
// ... 省略其它代码
#define __T(x) L ## x
// ... 省略其它代码
#else /* ndef _UNICODE */
// ... 省略其它代码
#define __T(x) x
// ... 省略其它代码
#endif /* _UNICODE */
当我们的工程的Character Set设置为Use Unicode Character Set时_T和_TEXT就会在常量字符串前面加L，否则(即Use Multi-Byte Character Set时)就会以一般的字符串处理。
6.总结一下
UNICODE宏和MBCS，对很多函数和宏有影响。
char* 也可以表示中文，wchar_t*也可以表示中文，只不过编码方式不同，一个是ANSI（多字节）字符集，一个是Unicode字符集。具体到编码方式，前者可能是变长的编码方式，后者应该是UTF16定长编码方式。
