人生于世，一味勤，不见得是好事。

与人处，得小懒。管头管脚，大到原则问题，小至鸡毛蒜皮，样样都想插一手。这样的相处模式，除了惹人厌，再难有其他结果。容他人藏点隐私，给彼此留点空间，这样的小懒，比起所谓的无微不至更令人欣赏。

与人言，也得小懒。话不能说得太满，意犹未尽之处，于人于已都是余地。留有这样的余地，日后才好转圜。同样的意思，横冲直撞与婉转留余，可能带来不同的结果。留一线，好相见，这样的留，自然是小懒。

为了提高项目的可维护性，我们通常会将不同用途的代码文件放到不同的文件夹中，如头文件放到include目录，源文件放到src目录，第三方库放到3rd目录等。

当使用CMake生成Visual Studio工程时，我们亦希望在Visual Studio中能看到这样的文件结构。当然，我们可以使用source_group指令进行添加，但当目录和层级很多时，这样添加起来就显得比较繁琐了，本文介绍一种懒人方法。

大道至简，越是根源和基本的问题，道理实际上越简单。关于如何做人、做事、做管理的书很多，我看得不多，但是我觉得这些书更多是侧重技术和实现细节上的，而很少从人的思想和观念去讲。从实际根本上去说，如何做人做事是世界观的问题，也是一个哲学话题。很多人和我一样，已经到了30的年纪，是需要去思考一下应该如何做人如何做事的，也需要一套简单、有效、完整的体系来指导自己，而这套体系将是让自己安身立命于这个世界的基石。

Electron 官方未提供判断当前程序运行环境的方法。我认为官方不提供这个方法也是说的过去的，因为 Electron 扮演的是应用开发框架的角色，而运行环境这些东西本身属于开发者自己的事情，有的开发者喜欢定义“开发、测试、预生产、生成”四个环境，而有的开发者却只定义了一个生产环境，这些都不是框架需要参与的事情。

启用调试工具

Electron 中打开调试窗口的方法有多种，但前提都需要在创建 Browser Window 时启用 devTools 特性，如：

1
2
3
4
5
6
7
8

const win = new BrowserWindow({
  width: 1080,
  height: 768,
  title: "test window",
  webPreferences: {
    devTools: true,
  },
});

HANDLE类型返回值的不确定性指的是Windows API函数的返回值为HANDLE类型时，有两种表示失败的方式：

• HANDLE == NULL，如CreateEvent等
• HANDLE == INVALID_HANDLE_VALUE，如CreateFile等

其中，NULL的值始终为0，而INVALID_HANDLE_VALUE的值为-1，其在32位和64位程序中分别等于0xFFFFFFFF和0xFFFFFFFFFFFFFFFF。

具体哪些函数失败时返回NULL，哪些返回INVALID_HANDLE_VALUE了？这个需要查阅MSDN文档来确定。

在C++98时代，我们经常会遇到这样的性能瓶颈：当需要返回或传递大型对象（如字符串、向量或自定义资源管理类）时，不得不进行昂贵的深拷贝操作。即使我们知道某些对象即将被销毁，也无法避免这种拷贝开销。

C++11引入的右值引用和移动语义彻底改变了这一局面，让C++程序员能够写出更高效、更现代的代码。

C++从C++11开始引入了智能指针（std::unique_ptr、std::shared_ptr、std::weak_ptr），并后面的各个版本中对智能指针进行了改进。

使用Qt静态库违背了Qt的免费使用协议！

编译

编译Qt源码需要提前安装如下工具：

• nasm
• perl
• gperf
• win_flex_bison
• llvm
• python2
• openssl

同一个DLL文件可以被多个进程加载。当不同的进程将DLL映射到自己的内存空间时，系统会为DLL中的全局和静态变量创建不同的实例，而不会共享同一个变量实例。

那我们如何实现在进程间共享DLL全局变量呢？
我们可以在DLL中使用如下语句来创建一个段，用来存放那些需要共享的变量：

1
2
3
4

#pragma data_seg("AnyName")  // 开始
// 声明变量
// ....
#pragma data_seg()   // 结束

共享的变量需要被初始化，并且还要设置链接器开关，使该段在所有映射DLL的进程中成为共享读写属性：

1
2

// 共享读写
#pragma comment(linker,"/SECTION:AnyName,RWS")

经过上述操作，共享的变量就可以跨不同进程进行读写操作了。