Coding is hard, you can make it easy!

前言

我在上一篇文章《5 个非常实用的 vs 调试技巧》 中分享了 5 个我认为非常值得了解的 vs 调试技巧，本周继续分享 5 个很基础但同样实用的调试技巧。

前言

调试是一项非常重要的技能，熟练掌握调试技巧有助于我们快速解决问题。vs 是我们平时编写代码时的首选工具，相信也是大多数小伙伴儿的首选调试工具，因为实际操作起来太方便了，代码编写完，一个 F5 就可以愉快的调试了。今天我想向大家推荐几个非常值得了解 vs 调试技巧。话不多说，我们开始吧。

缘起

最近在调试的时候，需要观察第三方容器中每一个元素的值。默认情况下，vs 并不知道如何显示第三方容器的内容，只能手动观察容器中的每一个值，超级不方便。我找到一个非常给力的好办法，你还知道其它好办法吗？

前言

这是 N 年前遇到的一个问题了。最近跟 DEBUG 宏对着干上了，正好翻到这篇总结 —— 记录了使用 pragma message 排查 同一个工程不同 CPP 中 DEBUG 宏的值不同的过程。现对之前的总结做了更新整理，分享给各位小伙伴儿。

缘起

在上一篇文章 《调试实战 | dll 加载失败之Debug Release争锋篇》中，由于两个工程中的 _ITERATOR_DEBUG_LEVEL 不同，导致了对同一个 map 的解析不同，从而导致了崩溃。在示例代码中，我是手动更改的该宏的值，在实际工程中，却另有玄机。在上文中故意省略了这部分内容的介绍。现把实际工程的问题在本文中做个相对详细的梳理总结。

先剧透一下：实际工程中的问题是因为一个工程中定义了 _DEBUG 宏，另外一个工程里没定义。但是我已经核对过，两个工程都没定义 _DEBUG 宏。其中一个工程的 _DEBUG 宏是从哪儿来的呢？

缘起

最近，项目里遇到一个 dll 加载不上的问题。实际项目比较复杂，但是解决后，又是这么的简单，合情合理。本文是我使用示例工程模拟的，实际项目中另有玄机，但问题的本质是一样的。本文从行文上与 《调试实战 | dll 加载失败之全局变量初始化篇》 非常相似，示例代码也非常相似（原谅我比较懒），感兴趣的小伙伴儿可以对比来读。

缘起

我在上一篇文章——《调试实战 | dll 加载失败之全局变量初始化篇》中，跟大家分享了一个由于全局变量初始化顺序导致的 dll 加载失败的例子。感兴趣的小伙伴儿可以点击阅读。

虽然我们知道了是由于全局变量初始化顺序导致的问题，也给出了解决方案。但是有一点却没有刨根问底——为什么改变文件在工程文件中的顺序就可以改变全局变量初始化顺序？是怎么影响的呢？本篇文章力求解决这个问题。

前言

最近项目里总是遇到 dll 加载不上的问题，原因各种各样。今天先总结一个虽然不是项目中实际遇到的问题，但是却非常经典的问题。其它几种问题，后续慢慢总结。

示例代码包含一个 exe 工程，两个 dll 工程。 exe 会加载两个 dll 并调用它们的导出函数（GetCallCount），结果只有一个 dll 的导出函数被成功调用。会是什么原因呢？

前言

相信，很多小伙伴儿都在命令提示符中执行过 ipconfig 查看 ip 信息。我们还可以执行 ping ip 来 ping 对应的 ip 地址，执行 notepad 启动记事本，执行 explorer 启动文件管理器……

但是，你好奇过背后的运作机制吗？为什么输入几个简单的几个字母就能启动外部程序，本文试图通过一系列实验来挖掘其背后的运作机制。

如果你对下面的问题有很明确的答案，本文不是为你准备的。如果有模糊，拿不准的地方，请耐心读完。如果觉得有用，请帮忙点个在看，拜谢。

缘起

前一段时间，有网友遇到一个奇怪的问题，说他机器上的 vs2019 编译 C++ 工程报错。我当时一听就有两个怀疑：

1. 工程设置不对。
2. vs2019 没装好。

因为新建一个最简单的工程，编译也报一样的错误，所以可以排除工程设置的问题了。那只有可能是 vs2019 的问题了。但是具体是哪里的问题呢？