分类目录归档：记录

GDB with Python

这篇文章的主要应用场景是调试Python的C/C++ Extension

  1. 同时使用pdb / gdb 进行调试. 通俗点说, 既可以break在 .py 文件中,也可以break在 .cc 文件中
  2. 在gdb中不但可以获得常规的调试信息, 还可以获得python VM 的调试信息, 例如获得python的调用栈, 访问Python局部变量等. 这将会在调试exception时(如Segmentfalut)非常有用, 这种场景下,
… Read More

Bazel Notes

这是一篇2019年左右的记录, 内容可能过时, 也不太全面

杂谈

Bazel是Google为Monorepo服务而开发的构建工具.

首先是巨大,当问题的规模变大,事情总是会变得更复杂. 而Google面对的"巨大Monorepo",应该是世间罕有的.

然后是Monorepo,这极大的影响了代码的组织风格.例如,你要写一个操作系统内核ProjectOS,还要写一个游戏ProjectGame.在传统的开发习惯中,这两个项目会组织到两个不同的Repo里,PorjectOS和ProjectGame之间无法直接相互引用,例如,你在ProjectOS里写了一个高级的数据结构,想要在Game里也使用,要么直接复制粘贴,要么是创建一个新的CommonRepo,把可公用的代码都放在Common里,然后两个项目各自引入Common作为依赖.

使用MonoRepo则不存在这个问题,Game可以直接依赖OS内的组件,按照Bazel的语法描述,就是在Game中可以直接使用@ProjectOS//path/to/package:AdvancedStruct.当然,你仍然可以选择重构一个Common出来,但是现在已经没有这种必要了.

从技术层面说,在使用"巨大Monorepo"时,Bazel相对现有编译系统的优势能充分展现.你的项目离"巨大Monorepo"越远,使用Bazel的优势就越不明显. 宽泛的来说,对于大部分项目,使用Bazel都不能带来明显的技术收益.

一般而言,使用Bazel的优势是并不是体现在技术层面.而是让你的代码能无痛使用谷歌的开源组件. 原因很简单, Google的项目都是基于Bazel的,如果你不用Bazel,就需要自己做一些额外的工作.

换个角度来看,这也是谷歌的"阴谋":如果Google外的开发者不用Bazel,那么当Google需要依赖外部项目时,就需要手动把这些项目转换成Bazel的;而如果全世界的程序都用Bazel来组织编译,那么Google就可以无缝的从开源世界汲取力量.

吹Bazel的帖子到处都有,所以这里只说黑点,如果这些黑点你并不很care,那么使用Bazel应该是个不错的选择

  1. Bazel是后来者,熟悉它的开发者比较少,加上学习成本高,可能需要有若干"Bazel"专家负责整个构建系统的维护.
  2. 对于已经成熟的大中型项目,迁移到Bazel的时间/人力成本会比较高,而这一般也不会带来明显的收益.最好在项目早期使用Bazel
… Read More

Unix related things

这是一篇2017年左右的记录, 仅用作分享

杂

  • 在shell内能干的事,我们都可以比较简单地通过系统调用实现.
  • `称为反引号,^称为脱字符,常用来表示CTRL
  • windows的系统调用是不开放的,windows下只能直接使用windows.h里的windows API.
  • /dev目录下的设备是供用于程序直接使用的,主要由block,char,pipe,socket类型
    • 并不是所有设备都能映射为这种形式
  • /sys/device/目录称为sysfs,他下面存放了所有设备的信息.(不能直接从/dev获得任何设备信息)
    • udevadm info
… Read More

Docker

这是一篇2017年左右的记录, 内容可能已经过时

  • Docker的image类似于Git的repo,而docker的tag则类似于git的branch
  • 由于内核共享, Docker container 里的uid/gid是和宿主机复用的, 所以相关的鉴权系统也和系统一致.
    • 用户名可能不一致, container内可以使用自己的用户名.
    • 可以使用 --user来指定docker container内所有进程的执行身份
  • Docker 可以近似为特化的虚拟机，除了Kernel外，所有的其余部分都可以是Docker独占的。
    • 例如，可以制作完整的OS镜像，这些OS镜像除了没有内核，其余都和正常的OS是一致的。
    • Docker之间的隔离相比VM要浅一些,可能存在一些安全问题;另一方面,VM则由于可攻击面更大,也有安全问题
  • Docker可以说是一个Utility, 并没有自创新技术,所以Docker中的技术主体为
… Read More

Shared Library

正确而高效的使用动态库是一个很复杂的话题,这需要开发者编译和链接有相当深入的理解.

… Read More

A note for cmake

A Note for CMake

CMake可以说是目前C++项目的标准构建系统, 尽管它有很多不足, 但是它已经成功的替换掉了autoconf这一代的构建工具. 除非有足够的理由, 在选择构建系统时, CMake总是应当第一优先考虑.

我熟悉的构建系统只有CMake和Bazel, 事实上, 如果能满足若干客观条件的话, 我更愿意使用Bazel, 不过这篇主要记录的是CMake, 所以还是以CMake为主. 在我看来, CMake主要的优缺点如下:

Pros:

  1. Imperative:
… Read More

IEEE 754 的 inf 比较问题

首先上结论: 当涉及浮点数比较时,一定要考虑比较符号两侧都是inf的情况.

原因: inf==inf,inf<=inf,inf=inf 这三个比较都为真(-inf同理),而这种结果可能与我们的期望不符.

解决方法:
1. 如果为真是可以接受的,那么直接使用比较运算符,例如a<=b
2. 如果为真是不可以接受的,那么应当使用作差,例如(a-b)<=0, 这种情况下,当a和b都为inf时,inf之间的运算会输出NaN,从而导致比较结果为false

例如,我有这样一个应用场景:

有射线R和两个平面S0及S1,我们需要求射线R与平面S0的交点p0,以及射线R与平面S1的交点P1. 且要求p0不能比p1离射线起点更远(可以重合)

假如我们用直线的参数方程来描述交点,显然,上面的目标很容易用 t0<=t1 … Read More

KD树与SKD树

KD树与SKD树

首先给出两个搜到的有点内容的KD树文章,论述的比我说的更完整(更冗长),可以先看,也可以看完本文再看.
* https://www.zybuluo.com/l1ll5/note/967681
* http://www.whudj.cn/?p=920

主体思想

  • KD树和SKD树都使用坐标轴对齐的最小包围盒来描述空间.
    • 例如,平面内,一堆点的点集对应的空间可以用点A=(min(all_x),min(all_y)),B=(max(all_x),max(all_y)) 对应的矩形空间来描述. 当点的个数变为1时,这个矩形空间也会自然地退化为一个点.
  • 构建时的主要思想: 每个节点
… Read More

设计模式

For C/C++ user

很多设计模式相关的资料都是用Java来描述的,有必要简单补充一下Java和C++在OOP技术层面上的区别

  • Java不支持任何形式的运算符重载
  • Java明确区分接口和类,类只能从一个类派生，但是一个类可以实现多个接口
  • 在Java中，所有方法默认是虚（virtual）的
  • 对CPP而言,Java风格的接口可以视为一个只有pure virtual
… Read More