blueyi's notes

默认的GCC编译选项会编译出与系统一致的输出，例如64位直接使用gcc或g++编译出的为64位程序或库，而32位系统编译的是对应32位的。
可以通过在编译时添加选项-m32或-m64来指定编译生成的相应版本，如果同时带上这2个选项，只有后一个会生效。
问题的关键时多数时候会提示缺少库，这里以64位下编译32位程序为例，给出ubuntu和centos下相关依赖包。

当安装了VS之后再安装CUDA套件就可以通过VS创建基于CUDA的项目，但往往我们会需要让之前的老项目支持对CUDA的编译，以便使用CUDA对原有项目中的部分算法加速，网上有各种各样的尝试，搜索SOF之后找到一个超简单的方法，记录之。

首先 Docker 是由 go 语言编写，基于 Linux 容器技术（LXC）、Namespace、Cgroup 和 UnionFS（联合文件系统）等技术的轻量级操作系统虚拟化解决方案。

对于 docker 的概念，可以简单理解如下：

• 镜像（Image） 类似于虚拟机的快照，它是只读，可以以镜像为模板创建容器，在容器中的更改不会影响到原镜像。实际镜像是 UnionFS 的层级文件系统。
• 容器（Container） 类似于轻量级的虚拟机，由 docker 镜像实例化而来，docker 推荐一个容器运行一个进程，可见其轻量程度。
• 注册服务器（Registry） 提供在线存放 docker 镜像的在线服务，可以理解为 github 所提供的 repository 作用，当我们使用 docker run 运行一个本地不存在的镜像时，默认情况下 docker 会从 docker 官方的 registry 拉取该镜像，然后创建并运行一个容器。
• Dockerfile 可以理解为用于构建镜像的命令和设置组合

本文将从安装开始，记录docker日常使用的一些命令、问题及深一点的理解

YUV 数据格式概览

YUV 的原理是把亮度与色度分离，使用 Y、U、V 分别表示亮度，以及蓝色通道与亮度的差值和红色通道与亮度的差值。其中 Y 信号分量除了表示亮度 (luma) 信号外，还含有较多的绿色通道量，单纯的 Y 分量可以显示出完整的黑白图像。U、V 分量分别表示蓝 (blue)、红 (red) 分量信号，它们只含有色彩 (chrominance/color) 信息，所以 YUV 也称为 YCbCr，C 意思可以理解为 (component 或者 color)。

维基百科上的 RGB 转 YUV 的公式能更好的反应 YUV 与 RGB 的关系，以及为什么称为 YCbCr：

Y 中含有三元色色信息，且有较多的 G，所以他们一起可以显示出全彩的图像。
很显然我们可以想到是不是会有 YCgCb、YCgCr 等，针对不同的应用场景，也确实有相关应用研究。

如下图，一张从上到下分别为原图、Y、U 和 V：

采用 YUV 而不是使用 RGB，既有历史原因：为了兼容老式黑白电视，因为 YUV 如果只输出 Y 就成了黑白图像了。也有 YUV 自己的其他优点，例如可以根据需要，采用特定的 YUV 存储格式，以降低祼码流的空间占用。

Windows 下的多线程中线程锁是通过CRITICAL_SECTION实现，用以保护用户数据，即当串行代码断执行到该部分时，操作系统将告知下一来执行到此处的线程等待，直到上一个线程离开被保护的代码断，从而通过将需要访问数据的部分放在该代码段来保护数据被多线程访问时的一致性。

生成coredump

当程序运行出现如下错误时：

1

Program terminated with signal 11, Segmentation fault   (core dumped).

系统会提示有coredump产生，但通常我们在系统文件夹下并找不到core文件，是因为系统设置产生core文件大小为0，也即不会产生，所以我们这里可以做一些简单的设置：

设置core文件产生在当前目录，%e表示产生core文件的程序名，%p为pid号：

1

echo "core.%e.%p" > /proc/sys/kernel/core_pattern  

查看当前core文件设置的大小：

1

ulimit -c

设置core文件大小为无限制：

1

ulimit -c unlimited

关于动态链接库和静态链接库的区别可以参考另一篇笔记，其实也就一句话：静态链接库在编译期加载到相应的编译目标中（编译后不再需要），而动态链接库是在运行期由执行目标进行调用（每次运行都需要）。
Windows下动态链接库以后缀.dll标识，Linux下的动态链接库命名为libxxx.so，其中xxx为库名称。

GTest简介

GTest是Google官方团队开发的开源的C++单元测试框架，地址为：https://github.com/google/googletest。该地址下同时有一个名为googlemock的项目，Google Mock可以理解为Google Test的辅助测试框架，Google Mock可以用于实现一个模拟类(mock类)，可以用于完成需要接口交互但相应的类又没有实现的测试。本文不涉及Mock，以后有空了再追加Google Mock的使用。
使用Google Test可以实现：
1、测试应该是独立并且可以重复的。
2、测试应该组织良好，能够清晰的反应出测试代码的结构。
3、测试应该是可移植和可利用的。
4、当测试失败时，Google Test将会提供尽可能多的测试信息，并继续后面的测试而不是结束测试。
5、Google Test会跟踪所有用户定义的新测试，而不需要用户一一再去调用它们。从而将测试人员从繁杂的测试用例调用中解放出来，将更多的精力关注中测试本身上。
6、测试实现起来很快，因为Google Test框架能够在测试用例之间共用资源，并且它们之前还不会相互依赖。

tmux主要的功能有两点：

• 终端利用，可以在一个terminal开启多个shell的session，这样就不需要vim一个terminal，命令又要需要一个，其他服务还要再开一个了。
• 断线保证任务在后台继续执行，以及当你上线后保证原来打开的多个窗口与断线之前完全一样。以后就不用再使用screen了

关于Makefile的编写和make命令的简单应用，快速了解Makefile的编写规则，更多功能将在以后的使用中慢慢增加。