箱猫日和 – Page 2 – Box Cat Happy Day

【C++11】异步执行之既有函数的包装：packaged_task类和async方法

上篇中讲到，C++11的标准库提供了promise用于在线程执行的具体方法中返回数据，接收端通过future阻塞获取。这么做的前提是你可以修改方法的参数，或者说你需要写一个包装函数。想要让既有函数异步的话，你可以使用packaged_task类或者async方法。

具体分析之前，以下代码是在线程中需要执行的方法。

MyString some_function() {
    return MyString{"foo"};
}

MyString some_function() {

return MyString{"foo"};

}

MyString是很早之前自己用来查看copy/move次数的类，不想用的话，可以替换为std::string。

packaged_task

packaged_task是一个封装了被调用的函数的task。注意，packaged_task本身并不提供异步执行的机制，所以你仍旧需要把packaged_task放到thread中去执行。

std::packaged_task<MyString()> task{some_function};
std::future<MyString> future = task.get_future();

std::thread task_thread{std::move(task)};
task_thread.join();

MyString string = future.get();
std::cout << string << std::endl;

std::packaged_task<MyString()> task{some_function};

std::future<MyString> future = task.get_future();

std::thread task_thread{std::move(task)};

task_thread.join();

MyString string = future.get();

std::cout << string << std::endl;

Continue reading “【C++11】异步执行之既有函数的包装：packaged_task类和async方法”

【C++11】基于std::thread异步执行时的输入输出

本篇主要是记录自己在学习C++11下std::thread异步执行时的一些细节性的东西，为之后基于C++11写并发代码打基础。

C++11引入了std::thread。据说之前因为需要区分对待pthread和win下的线程库，代码中有大量的预编译的if else，非常丑陋。现在的话，统一用std::thread就行了。

基于std::thread最简单的异步执行代码。

#include <iostream>
#include <thread>

void thread_run() {
    std::cout << "thread run\n";
}

int main() {
    std::thread thread1{thread_run};
    thread1.join();
    return 0;
}

#include <iostream>

#include <thread>

void thread_run() {

std::cout << "thread run\n";

}

int main() {

std::thread thread1{thread_run};

thread1.join();

return 0;

}

Continue reading “【C++11】基于std::thread异步执行时的输入输出”

【C++11】字符串与常用数据结构

学习一门编程语言，考察编程语言支持的基本数据结构是很重要的。如果你以前学的C/C++倾向于自己造轮子，或者你有其他语言背景的话，建议重新了解一下C++11 标准库中的数据结构。

字符串 std::string

你可以用 const char* 也就是字符串字面量来构造 std::string ，也可以从 std::string 中获取 C风格字符串的指针（const char*）。

std::string foo = "foo";
foo.c_str(); // const char*

1 2	std::string foo = "foo"; foo.c_str(); // const char*

std::string 是可变的，所以你可以修改 std::string 而不用太担心性能

std::string result;
result += "foo";
result += '@';
result += "example.com";

std::string result;

result += "foo";

result += '@';

result += "example.com";

关于不可变字符串，有很多讨论，这里列举一下想要用不可变的“字符串”话，在不用其他库的情况下可以怎么做

const char* 如果自己分配的字符串数组的话，需要记得delete。字符串字面量的话不用担心。
const std::string& 给 std::string 加const，严格来说这只是防止修改
自己造轮子

std::string 支持 copy 和 move

std::string 的 substr 返回的是 copy 过的子字符串。

C++17开始支持 string_view。在C++17之前想用“字符串视图”的话，你可能要自己构造一个类似下面这种包装结构

struct StringView {
    std::shared_ptr<std::string> str_ptr_;
    size_t start_;
    size_t end_;

    explicit StringView(
        std::shared_ptr<std::string>& str_ptr, 
        size_t start, 
        size_t end): str_ptr_{str_ptr}, start_{start}, end_{end} {
    }
};

struct StringView {

std::shared_ptr<std::string> str_ptr_;

size_t start_;

size_t end_;

explicit StringView(

std::shared_ptr<std::string>& str_ptr,

size_t start,

size_t end): str_ptr_{str_ptr}, start_{start}, end_{end} {

}

};

std::string 的 = 是字符串比较，而不是地址比较。

std::string 提供的相关方法不多，现有的比如查找find/rfind

std::string foo = "foo";
foo.find('f'); // 0
foo.find('a'); // not found, std::basic_string::npos

std::string foo = "foo";

foo.find('f'); // 0

foo.find('a'); // not found, std::basic_string::npos

需要注意找不到时返回的不是-1，而是npos，一个特殊的值

std::string 提供了两个获取字符的方法，at 和 []，前者加了范围检查，后者没有

支持用迭代器方式遍历字符串

std::string foo = "foo";
for(const char& ch: foo) {
    // do stuff
}

std::string foo = "foo";

for(const char& ch: foo) {

// do stuff

}

关于UTF-8字符串，可能和 std::string 没有直接关系，但是C++11中的字符串字面量

"foo"; // 1
u8"foo"; // 2

1 2	"foo"; // 1 u8"foo"; // 2

1是依赖于系统编码的字符串字面量，2是UTF-8编码的字符串字面量。

std::string 没有直接支持UTF-8的方法，size返回的是字节数，如果你用迭代器遍历的话，是按照逐个byte的方式（虽然类型叫char）

Continue reading “【C++11】字符串与常用数据结构”

【C++11】字符串拼接之回归原点

在其他语言里，字符串拼接可能是一个常见而且基本不会去注意的部分，但是在C++中字符串拼接有非常多的解决方法。造成这种现象的原因是，C++程序员想要高效地拼接字符串。

比如说下面的代码

std::string concat_string(const std::string& name, const std::string& domain) {
    return name + '@' + domain;
}

std::string concat_string(const std::string& name, const std::string& domain) {

return name + '@' + domain;

}

对于有非C/C++语言的人来说可能最平常不过的代码，C++程序员可能直觉上不会采用这种写法。那么C++里面该用什么写法呢？或者说最佳实践是什么？

这里不会列举各种字符串拼接的方式，如果你有兴趣可以在StackOverflow上搜搜看。个人想要说的是：在分析了C++11里字符串的操作之后个人给出的结论：C++11里最佳的字符串拼接其实就是上述写法。以下是具体分析。

Continue reading “【C++11】字符串拼接之回归原点”

【C++11】move构造函数和std::move

如果说新的语言特性使得过去的最佳实践不再成立的话，我想move构造函数和std::move所代表的move语义应该算其中一个。

在解释move引起的变化之前，这里先定义一个支持自定义move操作的类

class Foo {
public:
    explicit Foo(int value) : value_{value} {
        std::cout << "Foo(int)\n";
    }

    // copy
    Foo(const Foo &foo) : value_{foo.value_} {
        std::cout << "Foo(copy)\n";
    }

    // copy assignment
    Foo &operator=(const Foo &foo) = delete;

    // move
    Foo(Foo &&foo) {
        std::cout << "Foo(move)\n";
        value_ = foo.value_;
        foo.value_ = 0;
    }

    // move assignment
    Foo &operator=(Foo &&foo) {
        std::cout << "Foo(move assignment)\n";
        value_ = foo.value_;
        foo.value_ = 0;
        return *this;
    }

    int value() const {
        return value_;
    }

    void set_value(int value) {
        value_ = value;
    }

    ~Foo() {
        std::cout << "~Foo(" << value_ << ")\n";
    }

    friend std::ostream &operator<<(std::ostream &os, const Foo &foo) {
        os << "Foo(" << foo.value_ << ")";
        return os;
    }

private:
    int value_;
};

class Foo {

public:

explicit Foo(int value) : value_{value} {

std::cout << "Foo(int)\n";

}

// copy

Foo(const Foo &foo) : value_{foo.value_} {

std::cout << "Foo(copy)\n";

}

// copy assignment

Foo &operator=(const Foo &foo) = delete;

// move

Foo(Foo &&foo) {

std::cout << "Foo(move)\n";

value_ = foo.value_;

foo.value_ = 0;

}

// move assignment

Foo &operator=(Foo &&foo) {

std::cout << "Foo(move assignment)\n";

value_ = foo.value_;

foo.value_ = 0;

return *this;

}

int value() const {

return value_;

}

void set_value(int value) {

value_ = value;

}

~Foo() {

std::cout << "~Foo(" << value_ << ")\n";

}

friend std::ostream &operator<<(std::ostream &os, const Foo &foo) {

os << "Foo(" << foo.value_ << ")";

return os;

}

private:

int value_;

};

Continue reading “【C++11】move构造函数和std::move”

【C++11】从std::string str = “foo”说开去

最近因为某些原因决定重新开始学习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

Continue reading “【C++11】从std::string str = “foo”说开去”

Java并发研究自己写ReentrantLock和ReentrantReadWriteLock（4）

接上篇。在写完ReentrantLock之后，其实可以基于ReentrantLock写一个ReadWriteLock，《the art of multiprocessor programming》第八章有介绍。但是，本着不完全AQS（AbstractQueuedSynchronizer）介绍的系列主题，这里从零开始重新写一个ReentrantReadWriteLock。

按照ReadWriteLock的定义，任何时候都满足

没有线程持有锁
有1~n个线程持有共享锁（Read）
有1个线程持有独占锁（Write）

中的一个。

其次公平的ReadWriteLock要求新来的Read或者Write线程必须在队列中等待，非公平的ReadWriteLock允许新来的Read或者Write比队列中等待的线程先获取锁。关于非公平锁这里多说一句，理论上的非公平锁类似一群人哄抢的现象，但是实现多半是只允许新来和线程队列最前面的线程抢占锁。ReadWriteLock也是一样。如果你想要完全非公平的锁的话，可能AQS和这里的实现不满足你的需求。

为了实现ReadWriteLock的定义，你需要分别记录读写状态。考虑到独占（Write）状态只可能有一个线程，可能场景如下：

Continue reading “Java并发研究自己写ReentrantLock和ReentrantReadWriteLock（4）”

raspberry pi 3 b+ cross compile on macos mojave

本文记录了如何在mojave上构建raspberry pi 3 b+的交叉编译环境。交叉编译的原因最主要的还是速度，当然还有目标平台没有直接的编译工具链等。在构建交叉编译环境之前，最好确认目标平台的相关信息，能直接确认目标平台的工具链是最好的，因为从CPU判断可能并不准确。

比如raspebrry pi 3 b+，自带gcc，相关信息如下

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/6/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 6.3.0-18+rpi1+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-hecking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 6.3.0 20170516 (Raspbian 6.3.0-18+rpi1+deb9u1)

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/6/lto-wrapper

Target: arm-linux-gnueabihf

Configured with: ../src/configure -v --with-pkgversion='Raspbian 6.3.0-18+rpi1+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-hecking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf

Thread model: posix

gcc version 6.3.0 20170516 (Raspbian 6.3.0-18+rpi1+deb9u1)

注意其中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以外的系统，或者修改内核编译选项，这块等自己有空尝试并成功了再发出来）。

Continue reading “raspberry pi 3 b+ cross compile on macos mojave”

Compile and install valgrind on macOS Mojave (10.14.2)

本文是给想在Mojave上编译安装valgrind的人一个参考。

个人因为《Hands on concurrency with Rust》这本书的原因，需要安装valgrind。但是现在（2019/2/9）稳定版本的valgrind尚未支持Mojave，即不能通过Homebrew安装。valgrind的bug tracker里有这个问题的追踪，但是看状态估计离正式发布还需要时间（开源项目常有的事情，缺少资源，哎）。对话中给了一个github上的commit，看起来可以使用。

下载对应的repository，checkout到修改版的branch上

git clone https://github.com/Echelon9/valgrind.git
cd valgrind
git checkout feature/v3.14/macos-mojave-support-v2

git clone https://github.com/Echelon9/valgrind.git

cd valgrind

git checkout feature/v3.14/macos-mojave-support-v2

按照valgrind自身网站上的说明，接下来是常规的compile install。

./autogen.sh
./configure --prefix=foo
make
make install

./autogen.sh

./configure --prefix=foo

make

make install

如果你按照顺序执行的话，在make可能会碰到如下两个问题，所以在执行之前，建议先看一下可能碰到的问题

1. No rule to make target `/usr/include/mach/mach_vm.defs’

简单来说，就是没有找到定义文件。按照stackoverflow上一个问题的说法，你可以通过

xcode-select --install

1	xcode-select --install

解决，但是答案针对的不是Mojave，所以Mojave除了通过上述命令安装XCode之外，还需要解答中另外一个解决方案，即修改coregrind/Makefile（此文件在./configure之后生成)中mach_vm.defs的路径，具体如下

am__append_19 = \
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/mach_vm.defs \
        /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/task.defs \
        /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/thread_act.defs \
        /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/vm_map.defs

am__append_19 = \

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/mach_vm.defs \

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/task.defs \

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/thread_act.defs \

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/vm_map.defs

也就是在原本 /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

         Maximum build arch: amd64
         Primary build arch: amd64
       Secondary build arch:
                   Build OS: darwin
     Link Time Optimisation: no
       Primary build target: AMD64_DARWIN
     Secondary build target:
           Platform variant: vanilla
      Primary -DVGPV string: -DVGPV_amd64_darwin_vanilla=1
         Default supp files: exp-sgcheck.supp xfree-3.supp xfree-4.supp darwin10-drd.supp darwin18.supp

Maximum build arch: amd64

Primary build arch: amd64

Secondary build arch:

Build OS: darwin

Link Time Optimisation: no

Primary build target: AMD64_DARWIN

Secondary build target:

Platform variant: vanilla

Primary -DVGPV string: -DVGPV_amd64_darwin_vanilla=1

Default supp files: exp-sgcheck.supp xfree-3.supp xfree-4.supp darwin10-drd.supp darwin18.supp

假如Secondary build arch不像上面那样为空的话，比如是i386，那么make时会出现以上问题。

在 configure 文件中，valgrind的注释提到在MacOS下会同时编译i386和x86_64，这是问题的根本原因，或者说valgrind在Mojave下编译的坑。幸好 configure 提供了只编译64位的选项，不需要修改 configure 文件。

总结一下，你要做的是

./autogen.sh
./configure --prefix=foo --enable-only64bit
# 修改coregrind/Makefile
make
make install

./autogen.sh

./configure --prefix=foo --enable-only64bit

# 修改coregrind/Makefile

make

make install

小结

老实说很后悔升级到了Mojave，MacBook的睡死，突然mic不能使用等问题，现在又来一个valgrind……

不管怎么说，希望本文对你有所帮助。

如何理解 C++11 原子变量（Atomic）的 Memory Order

最近几天在学习Rust，把Rust官网附带的The Rust Programming Language看完，开始尝试用Rust实现自己学习过的并发数据结构。首先碰到的问题是，如何理解Rust所基于的LLVM的atomics模型。因为LLVM的原子变量模型基本可以对应于C++11开始的原子变量，除了没有consume memory order。所以任务就变成了如何理解C++11的原子变量。

C++原子变量本身并不难理解，但是理解memory order很难。网上找了很多资料，都没有很清晰得解释memory order到底是什么。今天重新看了《C++ Concurrency in Action》关于memory order的部分，对照着 std::memory_order 的介绍，突然明白了这是怎么一回事。

答案是memory order就只是一个order。

Continue reading “如何理解 C++11 原子变量（Atomic）的 Memory Order”