vs2015 相关使用

发表于 更新于 分类于 阅读次数： 本文字数： 2.7k 阅读时长 ≈ 2 分钟

post event

复制 release 文件到bin目录

copy $(OutDir)$(TargetFileName) $(SolutionDir)bin
copy $(OutDir)$(TargetName).pdb $(SolutionDir)bin

查看 utf8 变量

默认的, VC调试器只能正常显示ANSI字符串及UNICODE字符串, 而UTF-8字符串及其他格式则无法显示
这里无需编写插件及修改配置文件,只需要将要显示的字符串拉到Watch中,并在变量后面添加,s8即可显示

同样类型的功能也应该很熟悉

,数字  将变量拆分为数组显示, 数字是要显示多少位, 此法对const char*这类原始字符串非常有用
,x 16进制查看
,hr  查看Windows HRESULT解释
,wm Windows消息,例如0x0010, wm 显示 WM_CLOSE

保存为 unicode

file-save as 在save 旁边的三角 里面选择 unicode signiture 650001

缩放字体

Ctrl + Shift + .即可放大。
Ctrl + Shift + ，缩小。
这些字符分别是句点和逗号。

no symbols have been loaded

I hate this problem

MD MT 的选择

/MD 多线程、Release、DLL版本的运行时库
/MT 多线程、Release 版本的运行时库

  1. 为什么选择/MD，不选/MT？
    • 程序就不需要静态链接运行时库，可以减小软件的大小；
    • 所有的模块都采用/MD，使用的是同一个堆，不存在A堆申请，B堆释放的问题；
    • 用户机器可能缺少我们编译时使用的动态运行时库。（补充：如果我们软件有多个DLL，采用/MT体积增加太多，则可以考虑/MD + 自带系统运行时库）
  2. 为什么选择/MT，不选择/MD？
    • 有些系统可能没有程序所需要版本的运行时库，程序必须把运行时库静态链接上。
    • 减少模块对外界的依赖。
  3. 多个模块，必须选择相同的运行时库。

选择/MD需要注意多个模块使用不同版本运行时库的问题

多个dll被一个exe LoadLibrary加载，如果这些dll使用的运行时库是不同的，那么可能出现加载失败，原因可能是旧版本的运行时库已经在了，而某个dll它需要的是新版本的运行时库，旧版本不符合要求。

QA

error LNK2005: new and delete already defined in LIBCMTD.lib(new.obj)

I solve the problem by the following ways, please locate Project -> Properties -> Configuration Properties -> Linker -> Input at first.

In Debug mode:

Add uafxcwd.lib;Libcmtd.lib in Additional Dependencies.
Add uafxcwd.lib;Libcmtd.lib in Ignore Specific Default Libraries.
In Release mode:

Add uafxcw.lib;Libcmt.lib in Additional Dependencies.
Add uafxcw.lib;Libcmt.lib in Ignore Specific Default Libraries.
Notice:

Don’t miss the ; between the two .lib files.
A suffix -d must be added in the files in Debug mode.

A LIST_ENTRY has been corrupted (i.e. double remove)

Linker/Advanced/Randomized Base Address: switch from YES to NO.

https://software.intel.com/en-us/forums/intel-c-compiler/topic/621669

Hi,
The check-pointers-dangling option is a feature useful for debug configuration only. It tries to track the memory that is allocated and freed. Unfortunately, Windows address randomization tries to allocate memory from random addresses. This is not compatible with the dangling pointer checking, because repeated memory allocation calls may get very different addresses. BTW, I’ve confirmed with the development team on this as well and I have requested that the option elaboration of what I stated be added to the documentation pertaining to the feature as well. Thanks for catching this issue and bringing this to our attention, appreciate much.
Kittur

error “expected a string literal, but found a user-defined string literal instead” when using ‘extern “C”’?

When user-defined literals were introduced, it caused a small, breaking change to the language. String literals now need to be separated from a following identifier by whitespace, otherwise the the identifier is parsed as a user-defined literal operator:

"C"__declspec

One token, understood as a user-defined literal using the __declspec conversion.

"C" __declspec

Two tokens - the string literal “C” and the identifier __declspec.

You need to add a space to separate your tokens.