学习一门编程语言，考察编程语言支持的基本数据结构是很重要的。如果你以前学的C/C++倾向于自己造轮子，或者你有其他语言背景的话，建议重新了解一下C++11 标准库中的数据结构。 字符串 std::string 你可以用 const char* 也就是字符串字面量来构造 std::string ，也可以从 std::string 中获取 C风格字符串的指针（const char*）。 [crayon-648135ac10277948729400/] std::string 是可变的，所以你可以修改 std::string 而不用太担心性能 [crayon-648135ac1027e726520885/] 关于不可变字符串，有很多讨论，这里列举一下想要用不可变的“字符串”话，在不用其他库的情况下可以怎么做 const char* 如果自己分配的字符串数组的话，需要记得delete。字符串字面量的话不用担心。 const std::string& 给 std::string 加const，严格来说这只是防止修改 自己造轮子 std::string 支持 copy 和 move std::string 的 substr 返回的是 copy 过的子字符串。 C++17开始支持 string_view。在C++17之前想用“字符串视图”的话，你可能要自己构造一个类似下面这种包装结构 [crayon-648135ac10280212047184/] std::string 的 = 是字符串比较，而不是地址比较。 std::string 提供的相关方法不多，现有的比如查找find/rfind [crayon-648135ac10283936512340/] 需要注意找不到时返回的不是-1，而是npos，一个特殊的值 std::string 提供了两个获取字符的方法，at 和 […]

在其他语言里，字符串拼接可能是一个常见而且基本不会去注意的部分，但是在C++中字符串拼接有非常多的解决方法。造成这种现象的原因是，C++程序员想要高效地拼接字符串。 比如说下面的代码 [crayon-648135ac1065e776740619/] 对于有非C/C++语言的人来说可能最平常不过的代码，C++程序员可能直觉上不会采用这种写法。那么C++里面该用什么写法呢？或者说最佳实践是什么？ 这里不会列举各种字符串拼接的方式，如果你有兴趣可以在StackOverflow上搜搜看。个人想要说的是：在分析了C++11里字符串的操作之后个人给出的结论：C++11里最佳的字符串拼接其实就是上述写法。以下是具体分析。

如果说新的语言特性使得过去的最佳实践不再成立的话，我想move构造函数和std::move所代表的move语义应该算其中一个。 在解释move引起的变化之前，这里先定义一个支持自定义move操作的类 [crayon-648135ac11377573987677/]

最近因为某些原因决定重新开始学习C++。考虑到自己在大学里面学到的C++有点旧（估计是C++98），所以打算从C++11开始。 C++11如其名，是2011年出来的标准，所以2011年之后才有编译器实现。现在2019年大部分PC以及服务器应该都支持C++11了。 个人习惯于看书来学习某样东西，所以找了C++相关书的资料。一开始在o’reilly上找，发现很多书都比较旧。虽然有Effective C++以及More Effective C++系列，但对于初学者来说还不是时候。最后在Stackoverflow上找到了一个比较全的推荐书列表 https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list

本文记录了如何在mojave上构建raspberry pi 3 b+的交叉编译环境。交叉编译的原因最主要的还是速度，当然还有目标平台没有直接的编译工具链等。在构建交叉编译环境之前，最好确认目标平台的相关信息，能直接确认目标平台的工具链是最好的，因为从CPU判断可能并不准确。 比如raspebrry pi 3 b+，自带gcc，相关信息如下 [crayon-648135ac12181141043557/] 注意其中target为arm-linux-gnueabihf。假如从raspberry pi 3 b+的CPU（Broadcom BCM2837 64bit CPU）判断的话，armv8，aarch64貌似都可以用，但实际用aarch64架构编译出来的程序无法在raspberry pi，准确来说是安装了raspbian上的raspberry pi上执行，这点请注意（假如想在raspberry pi 3 b+上执行aarch64架构的程序的话，个人觉得可能要换raspbian以外的系统，或者修改内核编译选项，这块等自己有空尝试并成功了再发出来）。

本文是给想在Mojave上编译安装valgrind的人一个参考。 个人因为《Hands on concurrency with Rust》这本书的原因，需要安装valgrind。但是现在（2019/2/9）稳定版本的valgrind尚未支持Mojave，即不能通过Homebrew安装。valgrind的bug tracker里有这个问题的追踪， 但是看状态估计离正式发布还需要时间（开源项目常有的事情，缺少资源，哎）。对话中给了一个github上的commit，看起来可以使用。 下载对应的repository，checkout到修改版的branch上 [crayon-648135ac12375914930001/] 按照valgrind自身网站上的说明，接下来是常规的compile install。 [crayon-648135ac12379587762512/] 如果你按照顺序执行的话，在make可能会碰到如下两个问题，所以在执行之前，建议先看一下可能碰到的问题 1. No rule to make target `/usr/include/mach/mach_vm.defs’ 简单来说，就是没有找到定义文件。按照stackoverflow上一个问题的说法，你可以通过 [crayon-648135ac1237b268105521/] 解决，但是答案针对的不是Mojave，所以Mojave除了通过上述命令安装XCode之外，还需要解答中另外一个解决方案，即修改coregrind/Makefile（此文件在./configure之后生成)中mach_vm.defs的路径，具体如下 [crayon-648135ac1237d445427002/] 也就是在原本 /usr/include/mach/mach_vm.defs 等文件前加上 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk 前缀，你可以 ls 一下看一下文件是否存在。 2. vgpreload_core_x86_darwin_so-vg_preloaded.o ld: symbol(s) not found for architecture i386 这个问题比较隐蔽，google搜不出来什么东西。直接看错误信息的话，大概知道MacOS下无法链接i386的程序，因为比较新的MacOS基本上只有x86_64。直接的解决方法是不让valgrind去编译i386架构的程序。 如果你留意了 ./configure 最后的输出的话，可以看到Secondary build arch [crayon-648135ac1237e868801481/] 假如Secondary build arch不像上面那样为空的话，比如是i386，那么make时会出现以上问题。 在 configure 文件中，valgrind的注释提到在MacOS下会同时编译i386和x86_64，这是问题的根本原因，或者说valgrind在Mojave下编译的坑。幸好 configure […]