Coding is hard, you can make it easy!

回首 2021

2021 年真是又忙又累的一年，一直在加班，清明加，五一加，周末更别提了。一直忙到年底，才真正休息了几天。2021 真的是在忙碌中度过的，好在努力没有白费，付出了不少，也收获了很多：

• 交付的项目得到了客户的认可。
• 我们的团队在不断壮大成长。
• 我们的工作流程在持续优化中。
• 我们的技术交流依旧在持续举办中。
• 我们开始 code review 啦。
• 我们开始全面拥抱 git 啦。

前言

前两篇文章 part1 和 part2 基本上理清了 IsSplitter() 运行缓慢的原因 —— 在函数内部使用了带 Compile 选项的正则表达式。

但是没想到在 IsSplitter() 内部使用不带 Compiled 选项的正则表达式，整个程序运行起来非常快，跟静态函数版本的运行速度不相上下。又有了如下疑问：

1. 为什么使用不带 Compiled 选项实例化的 Regex 速度会这么快？
2. 为什么把 Regex 变量从局部改成全局变量后运行速度有了极大提升？除了避免重复实例化，还有哪些提升？
3. 为什么 PerfView 收集到的采样数据，大部分发生在 MatchCollections.Count 内部，极少发生在 Regex 的构造函数内部？（使用带 Compiled 选项的正则表达式的时候）
4. Regex.IsMatch() 是如何使用缓存的？
5. 直接实例化的 Regex 对象会使用正则表达式引擎内部的缓存吗？
6. 正则表达式引擎内部根据什么缓存的？
7. 什么时候会生成动态方法？生成的动态方法是在哪里调用的？

本文会继续使用 Perfview 抓取一些关键数据进行分析，有些疑问需要到 .NET 源码中寻找答案。在查看代码的过程中，发现有些逻辑单纯看源码不太容易理解，于是又调试跟踪了 .NET 中正则表达式相关源码。由于篇幅原因，本篇不会介绍如何下载 .NET 源码，如何调试 .NET 源码的方法。但是会单独写一篇简单的介绍文章 。

前言

我在上一篇文章《性能优化 | 记一次 .NET 程序的性能优化实战（1）—— 使用 process explorer 快速定位问题代码》中用 process explorer 定位到了导致程序运行缓慢的原因——使用了 .NET 中的正则表达式。.NET 中的正则表达式真这么慢吗？带着疑问，开始了本次的探索之旅。喜欢刨根问底的小伙伴儿快来一起看看吧！

前言

在前面两篇文章 记一次曲折的多资源文件拆分折腾过程（1） 和 记一次曲折的多资源文件拆分折腾过程（2） 中，已经把折腾过程中遇到的问题都弄清楚了。因为对这个问题印象太深刻了，而且 git 又是开源的，于是特地翻看了 git 的源码，并且在 windows 上用 gdb 简单调试了一波。

说明： 本篇文章适合 geek 阅读，全是一些源码查看及编译环境+调试的总结。

前言

本篇是上篇文章—— 记一次曲折的多资源文件拆分折腾过程（1） 的续篇。在上篇文章找到了导致编译报错的根本原因是 .rc 文件的编码不再是默认的 UTF-16LE-BOM 了。但是为什么 .rc 文件的编码会发生变化，并没有深究。本文继续探究一下。

缘起

最近这些天，我一有时间就捣鼓 .rc 。用 git 管理过 .rc 文件的小伙伴儿应该都知道，.rc 文件会被 git 默认当作二进制文件来管理。每次合并代码的时候，只要涉及到 .rc 文件的变更，很大概率会报冲突，而且工具不能很好的解决，只能手动解决。为了解决这个问题，我想到了两个方案：

1. 让 git 把 .rc 文件当成普通文件来管理。
2. 把一个大的 .rc 文件拆成多个小的 .rc 文件，这样可以有效的降低冲突的概率。

这两个方案相互之间没有任何冲突，所以这次折腾的时候，这两个方案是同时进行的。本以为没什么值得写的，没想到收获了意外惊喜，于是有了本篇总结。

缘起

因为需要分析 tfs 提交日志，并按照一定条件（比如，提交信息或者用户名）分类整理，特意写了这个小工具。在使用过程中发现，某些情况下会花费很长时间才能返回处理结果，当时稍稍做了一些优化，已经能满足当时的应用场景了。但是在处理大文件的时候依然会花费很长时间。忍了这么久了，终于有机会做一次效率优化了。

缘起

目前开发是在华为云桌面里进行的，在远端机器上装了 v15.05 版（很老的版本了）的 process explorer。但是今天打开 process explorer 后，Process Name 列消失不见了。

缘起

前一段时间，想使用 .net 监听特定文件夹中的文件是否发生变化。网上一搜，可以使用 .net 官方提供的 FileSystemWatcher，很开心的写好了代码。随着使用的不断深入，发现了 FileSystemWatcher 几个不够完善的地方。比如，

1. 事件触发时，文件可能还不能被访问。
2. 如果监听选项设置的过多，则有可能会触发多次文件变化事件。
3. 监听过滤器不够灵活，我没找到同时监听多种特定文件类型的方法。比如，同时只监听 .docx 和 .bmp 文件。

鉴于此，基于 .net 官方提供的 FileSystemWatcher，我又封装了一个新的类。可以在一定程度上解决以上几个问题。

前言

前几天，同事在 .net 程序中，遇到一个很 “诡异” 的问题：明明两个值是相等的，可偏偏却不相等，这是怎么回事呢？

缘起

磁盘已经全面爆红很久了，使用 dism++ 清理了几次，依然很紧张。终于，昨天在编译程序的时候又因为磁盘空间不足失败了！是可忍熟不可忍。必须安排！

缘起

前阵子，朋友遇到一个 .net 程序启动不起来的问题。根据之前的经验，一般是依赖的动态库加载失败导致的。或者找不到（依赖的动态库没有放到相应的目录下，一般放到应用程序所在目录即可），或者不匹配（64 位的程序加载 32 位的动态库，或者 32 位的程序加载 64 位的动态库）。整个排查过程并不复杂，本文不打算介绍整个排查过程，而是想介绍一些 .net 程序的基本常识（比如，以 Any CPU 编译出来的程序，是 32 位的还是 64 位的？），还会介绍几个我认为不错的查看工具。

缘起

前几天，修复 bug 后，本地测试通过，提交代码到 tfs，关闭 bug。但是客户拿到程序后，效果依然不对。来来回回检查了好几遍，逻辑是正确的，本地验证通过了，代码也确实上传到 tfs 了，但是程序到客户手里，效果确实不对。如果是你，该如何调（shuai）查（guo）呢？

说明：本文只是分享一种排查问题的思路。

前言

最近，在项目里遇到一个很 “诡异” 的问题。明明把后面需要使用的值存起来了，可是使用的时候，却拿到了一堆垃圾数据。有可能是什么原因呢？一起来看看吧。

回首 2020

2020 年基本上按照计划做到了周更。虽然每篇文章的阅读量都不高，但是每一篇都很用心的在写。能对一部分小伙伴儿有启发就值了。写这个公众号的初衷本来就是希望能给遇到相同或相似问题的小伙伴以启发。

2020 收获：

1. 坚持写了一年原创，围绕着调试，排错，性能优化，软件开发写了52+ 篇原创文章。其中，一篇看雪精华，三篇优秀。
2. 认识了很多新朋友，也认识了很多优秀的大佬。
3. 更佛系了。

展望 2021

不管怎样，令人沮丧的 2020 已经过去了，充满希望的 2021 已经来了。本公众号还会继续更新，但是更新频率会有所降低。

2021 为本公众号立几个 flag ，希望都能完成，欢迎各位朋友督促。

1. 至少更新 12 篇原创，争取做到每月一篇。
2. 争取再拿一篇看雪精华，至少一篇优秀。
3. 写一篇关于系统优化的实战。目前还没有写一篇真正让自己满意的优化文章。
4. 坚持分享更多书籍，至少 12 本。

开工福利

2021 希望大家都有新的收获。包邮送四本技术书籍给大家。抽四个幸运儿，每人一本。下周一（2021 年 1月 11 日）0 点开奖。

注意：本次抽奖仅限老粉丝（2021 年 1 月 4 日之前就关注了 公众号 【编程难】 或者 【比目信息】 的小伙伴儿）参与。

《软技能 代码之外的生存指南》

《程序员的自我修养：链接、装载与库》

《Effective C++：改善程序与设计的55个具体做法》

《深度探索C++对象模型》

前言

产品信息是向用户展示自家产品的直接方式。虽然是否有产品信息对程序功能没有任何影响，但是程序如果缺少了产品信息给人的感觉是不够正规！作为一名负责任的开发人员，你一定想为自己写的程序添加产品信息。你知道该如何添加吗？如何自动更新版本信息吗？

缘起

最近，接连在项目中遇到了两个界面无响应的问题。都只发生在客户特定机器上，不方便直接调试，只能抓取 dump 进行事后分析了。

前言

我在上一篇文章中介绍了几种误用智能指针的例子。还有一种比较典型，就是混用两种类型的智能指针。直接看代码吧！

缘起

一般情况下链接错误很好解决，最常见的是重定义和找不到外部符号，不过这次遇到的链接错误有些奇怪，一起来看看吧。

前言

智能指针的出现大大减轻了 C++ 程序员的心理负担（最少对于我是这样的），不用再时时刻刻担心一个 new 出来的指针是否被 delete 的问题了。虽然智能指针很强大，但是如果用不好，还是会导致各种各样的问题。最近，在项目里看到了几种智能指针的典型错误用法。有的严重，有的轻，有的问题在研发阶段并没有立刻暴露出来，埋下了一颗定时炸弹。趁着这个机会，总结一下几种常见的错误用法。希望对各位小伙伴儿有帮助。