发表于
字数统计 165 字 | 阅读时长 1 分钟

该方法在PHP 5.6.0及其以上版本可以用

我们直接来看一段代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php

class Foo
{
    public function __debugInfo()
    {
        return [
            'one' => 1,
            'two' => 2,
        ];
    }
}

var_dump(new Foo);

输出结果如下：

1
2
3
4
5
6
object(Foo)#1 (2) {
  ["one"]=>
  int(1)
  ["two"]=>
  int(2)
}

可以发现，使用var_dump的时候，会去调用__debugInfo魔术方法。这个方法对于调试还是比较有用，比如我们写PHP的C扩展，如果自定义了类对象，我们如果想要输出struct里面的信息，就可以去实现__debugInfo方法，然后在这个方法中去获取struct里面的信息，作为数组返回。

发表于
字数统计 539 字 | 阅读时长 1 分钟

最近我在关注PHP8的代码和变更，贡献了一些代码，这里想总结一下。

保留php-src仓库

因为php-src项目还是比较大的，所以我们每次去clone这个仓库是非常耗时的，所以我们可以先把github上面的php-src在gitee.com上面做一个镜像，然后再从gitee上面clone下来，最后修改一个git remote信息即可。而且这个仓库不要删除，留着来git pull

编译问题

因为我们在master分支进行工作，所以免不了要经常编译，我们一定要习惯make clean。而且我发现这个make clean也清理不干净构建出来的文件，有一些需要自己手动去删除。举个例子，词法分析的文件，编译出来的文件，make clean没有去删除，这就导致我某次编译失败了。

还有就是，如果我们直接./configure，然后编译，会编译比较久，因为它会编译好多扩展，所以我如果只看核心的东西，我会加上--disable-all。

stub文件

我们在内核代码中，经常会看到很多的stub文件，这些文件其实是用来生成函数的arginfo信息的。所以我们不要去手写函数的arginfo信息。我们可以通过gen_stub.php这个脚本来实现，生成方法如下：

1
php build/gen_stub.php

或者指定文件：

1
php build/gen_stub.php 某个stub文件

因为跑这个脚本需要nikic写的PHP-Parser，而PHP-Parser需要安装tokenizer扩展，所以我们需要一个安装了tokenizer扩展的php来执行它，并且php的版本要是7.1+。

测试

我们改动了PHP内核，难免会导致一些测试失败，所以我们需要去修改失败的测试。运行单个测试文件，我们可以这么做：

1
php run-tests.php 失败的那个.phpt文件

时间问题

因为PHP开发组的人大部分是在国外，由于时差问题，国内时间是下午和晚上他们会和我们交流，国内时间早上问问题基本不回了。

发表于
字数统计 133 字 | 阅读时长 1 分钟

本文基于的commit为：e93d20ad7ebc1075ef1248a663935ee5ea69f1cd

昨天（2020-6-30），有一个宏被加入到了PHP8里面，用来快速获取一个类名字或者对象的zend_class_entry结构，在PHP7里面，如果我们要去获取类，我们必须得这么做：

1
2
3
4
5
6
7
8
9
10
11
zval *arg;
zend_class_entry *ce = NULL;

zend_parse_parameters(ZEND_NUM_ARGS(), "z", &arg)

if (Z_TYPE_P(arg) == IS_OBJECT) {
    ce = Z_OBJ_P(arg)->ce;
} else if (Z_TYPE_P(arg) == IS_STRING) {
    ce = zend_lookup_class(Z_STR_P(arg));
}
RETURN_STR_COPY(ce->name);

现在，有了Z_PARAM_CLASS_NAME_OR_OBJ宏，我们可以非常方便的去实现这个操作：

1
2
3
4
5
ZEND_PARSE_PARAMETERS_START(1, 1)
    Z_PARAM_CLASS_NAME_OR_OBJ(ce)
ZEND_PARSE_PARAMETERS_END();

RETURN_STR_COPY(ce->name);

发表于
字数统计 209 字 | 阅读时长 1 分钟

本文基于的php-src commit为：915abeb6995bad124c325c69b8c44de65da36879

由于我经常需要去拉php-src的master分支代码的代码，然后时不时需要重新编译php，然后出了一个这个问题：

1
2
3
4
5
6
Zend/zend_language_scanner.l:309:15 error conflicting types for 'zend_lex_tstring'
    ZEND_API int zend_lex_tstring(zval *zv, zend_lexer_ident_ref ident_ref)

In file included from Zend/zend_language_scanner.l:40:0:
php-src/Zend/zend_language_scanner.h:81:14: note: previous declaration of 'zend_lex_tstring' was here
    ZEND_API int zend_lex_tstring(zval *zv, zend_lexer_ident_ref ident_ref)

这个问题是因为在php-src下面跑make clean无法清理完所有编译出来的东西（包括词法分析器编译出来的.c文件），所以，我们这里跑完make clean后需要自己手动去删除这些没删干净的东西（例如zend_language_scanner.c）。如何判断要删除哪些呢？也很简单，只要这个文件没有加入到git仓库，我们就可以删除。

发表于
字数统计 1.9k 字 | 阅读时长 8 分钟

最近在给Swoole的内核代码做覆盖率测试，我们测试的是Swoole的core-tests对libswoole的代码覆盖率，这个过程中遇到了一些问题，所以总结下。

基本流程

我通过一个简单的例子来进行讲解。

首先，定义一些函数（可以理解为libswoole）：

1
2
3
4
5
6
7
8
9
10
11
12
13
// lib.c
void func1(int a) {
    if (a > 0) {
        a--;
    } else {
        a++;
    }
}

void func2() {
    int b = 0;
    b++;
}

然后在main函数去调用这些函数（可以理解为core-tests）：

1
2
3
4
5
6
7
8
9
10
11
// gcov.c
extern void func1(int a);
extern void func2();

int main(int argc, char const *argv[])
{
    func1(1);
    func2();

    return 0;
}

然后我们开始测试覆盖率。首先是编译我们需要测试的库，也就是lib.c这个文件：

1
2
3
4
5
6
[root@a896c4eb1fc4 gcov]# ls
gcov.c  lib.c

[root@a896c4eb1fc4 gcov]# gcc --coverage -c lib.c
[root@a896c4eb1fc4 gcov]# ls
gcov.c  lib.c  lib.gcno  lib.o

我们发现，如果我们在编译文件的时候加上了--coverage，那么就会为这个文件产生一个对应的.gcno文件。

接着编译出可执行文件：

1
2
3
4
[root@a896c4eb1fc4 gcov]# gcc lib.o gcov.c -lgcov
[root@a896c4eb1fc4 gcov]# ls
a.out  gcov.c  lib.c  lib.gcno  lib.o
[root@a896c4eb1fc4 gcov]#

现在，我们执行这个可执行文件：

1
2
3
4
[root@a896c4eb1fc4 gcov]# ./a.out
[root@a896c4eb1fc4 gcov]# ls
a.out  gcov.c  lib.c  lib.gcda  lib.gcno  lib.o
[root@a896c4eb1fc4 gcov]#

我们发现，当执行完可执行文件之后，会为我们代测试的文件产生一个.gcda文件（我们需要记住的一点就是，一定要生成了.gcda文件之后，才可以看到覆盖率）。

然后，我们就可以测试lib.c的覆盖率了：

1
2
3
4
5
6
[root@a896c4eb1fc4 gcov]# gcov lib.c
File 'lib.c'
Lines executed:88.89% of 9
Creating 'lib.c.gcov'

[root@a896c4eb1fc4 gcov]#

可以看出，lib.c的测试覆盖率是88.89%。

但是，光看这一点信息是看不出到底是没有覆盖到哪些代码。

此时，我们注意到，多了一个.gcov文件：

1
2
3
[root@a896c4eb1fc4 gcov]# ls
a.out  gcov.c  lib.c  lib.c.gcov  lib.gcda  lib.gcno  lib.o
[root@a896c4eb1fc4 gcov]#

我们可以看一下这个文件内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[root@a896c4eb1fc4 gcov]# cat lib.c.gcov
        -:    0:Source:lib.c
        -:    0:Graph:lib.gcno
        -:    0:Data:lib.gcda
        -:    0:Runs:1
        -:    0:Programs:1
        1:    1:void func1(int a) {
        1:    2:    if (a > 0) {
        1:    3:        a--;
        -:    4:    } else {
    #####:    5:        a++;
        -:    6:    }
        1:    7:}
        -:    8:
        1:    9:void func2() {
        1:   10:    int b = 0;
        1:   11:    b++;
        1:   12:}
[root@a896c4eb1fc4 gcov]#

其中，标记为1的代表覆盖到了，标记为#####代表没有覆盖到。

所以，我们需要修改一下我们的测试代码，来覆盖到这一行：

1
2
3
4
5
6
7
8
9
10
11
extern void func1(int a);
extern void func2();

int main(int argc, char const *argv[])
{
    func1(1);
    func1(-1);
    func2();

    return 0;
}

然后重新编译可执行文件：

1
[root@a896c4eb1fc4 gcov]# gcc lib.o gcov.c -lgcov

然后重新执行可执行文件：

1
[root@a896c4eb1fc4 gcov]# ./a.out

然后重新测试覆盖率：

1
2
3
4
5
6
[root@a896c4eb1fc4 gcov]# gcov lib.c
File 'lib.c'
Lines executed:100.00% of 9
Creating 'lib.c.gcov'

[root@a896c4eb1fc4 gcov]#

可以发现，测试覆盖率达到了100.00%。

通过lcov可视化结果

除了用gcov来查看覆盖率之外，我们还可以用lcov来生成html页面来看覆盖率：

1
2
3
4
5
6
7
8
9
10
[root@a896c4eb1fc4 gcov]# lcov --directory . --capture --output-file coverage.info
Found gcov version: 4.8.5
Scanning . for .gcda files ...
Found 1 data files in .
Processing lib.gcda
Finished .info-file creation

[root@a896c4eb1fc4 gcov]# ls
a.out  coverage.info  gcov.c  lib.c  lib.gcda  lib.gcno  lib.o
[root@a896c4eb1fc4 gcov]#

此时生成了文件coverage.info。

其中，--directory用来指定.gcda文件的目录。现在我们的.gcda是在当前目录。假设我们不知道.gcda文件的路径，我们可以通过如下方法来查看：

1
2
3
[root@a896c4eb1fc4 gcov]# strings a.out | grep gcda
/root/codeDir/cCode/test/gcov/lib.gcda
[root@a896c4eb1fc4 gcov]#

然后我们可以通过如下命令来看覆盖率：

1
2
3
4
5
6
7
8
9
10
[root@a896c4eb1fc4 gcov]# lcov --list coverage.info
Reading tracefile coverage.info
            |Lines       |Functions  |Branches
Filename    |Rate     Num|Rate    Num|Rate     Num
==================================================
[/root/codeDir/cCode/test/gcov/]
lib.c       | 100%      9| 100%     2|    -      0
==================================================
      Total:| 100%      9| 100%     2|    -      0
[root@a896c4eb1fc4 gcov]#

然后，我们可以去生成html文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[root@a896c4eb1fc4 gcov]# genhtml -o report_dir coverage.info
Reading data file coverage.info
Found 1 entries.
Found common filename prefix "/root/codeDir/cCode/test"
Writing .css and .png files.
Generating output.
Processing file gcov/lib.c
Writing directory view page.
Overall coverage rate:
  lines......: 100.0% (9 of 9 lines)
  functions..: 100.0% (2 of 2 functions)

[root@a896c4eb1fc4 gcov]# ls report_dir/
amber.png  emerald.png  gcov  gcov.css  glass.png  index-sort-f.html  index-sort-l.html  index.html  ruby.png  snow.png  updown.png
[root@a896c4eb1fc4 gcov]#

（我们用浏览器打开index.html文件就可以看到覆盖率信息了）

gcov实现原理

gcc编译的时候，如果加上了--coverage覆盖率测试选项后，gcc会作如下处理：

  1. 在输出目标文件中留出一段存储区保存统计数据
  2. 在源代码中每行可执行语句生成的代码之后附加一段更新覆盖率统计结果的代码。（若用户进程并非调用exit正常退出，覆盖率统计数据就无法输出，也就无从生成报告了）
  3. 在可执行文件进入main函数之前调用gcov_init内部函数初始化统计数据区，并将gcov_exit内部函数注册为exit handlers
  4. 可执行文件调用exit正常结束时，gcov_exit函数得到调用，其继续调用__gcov_flush函数输出统计数据到*.gcda文件中

服务器程序一般启动后就很少主动退出，用kill杀死进程强制退出时就不会调用exit，因此没有覆盖率统计结果产生。为了解决这个问题，我们可以给待测程序增加一个signal handler，拦截SIGHUP、SIGINT、SIGQUIT、SIGTERM等常见强制退出信号，并在signal handler中主动调用exit或__gcov_flush函数输出统计结果即可。

这种方案会修改我们的待测程序，所以，我们可以通过动态库预加载技术和gcc扩展的constructor属性，然后将signalhandler和其注册过程都封装到一个独立的动态库中，并在预加载动态库时实现信号拦截注册。

我们来举个例子，修改一下我们的测试库：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// lib.c
void func1(int a) {
    if (a > 0) {
        a--;
    } else {
        a++;
    }
}

void func2() {
    int b = 0;
    b++;
    sleep(-1);
}

然后重复上面的过程：

1
2
3
4
5
6
7
8
9
[root@a896c4eb1fc4 gcov]# yes | rm -r a.out \
coverage.info \
lib.gcda \
lib.gcno \
lib.o \
report_dir
[root@a896c4eb1fc4 gcov]# gcc --coverage -c lib.c
[root@a896c4eb1fc4 gcov]# gcc lib.o gcov.c -lgcov
[root@a896c4eb1fc4 gcov]# ./a.out

我们会发现，我们的程序阻塞了，不会退出。此时，我们按CTRL + C来退出进程：

1
2
3
4
5
[root@a896c4eb1fc4 gcov]# ./a.out
^C
[root@a896c4eb1fc4 gcov]# ls
a.out  gcov.c  lib.c  lib.gcno  lib.o
[root@a896c4eb1fc4 gcov]#

我们发现，不会生成.gcda文件，所以我们需要去捕获退出信号。我们来编写一下我们的预加载动态库：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// preload.c
#include <stdlib.h>
#include <signal.h>

extern void __gcov_flush();

void sighandler(int signo)
{
    __gcov_flush();
}

__attribute__ ((constructor)) void ctor()
{
    int sigs[] = { SIGILL, SIGFPE, SIGABRT, SIGBUS, SIGSEGV, SIGHUP, SIGINT, SIGQUIT, SIGTERM };
    int i;
    struct sigaction sa;

    sa.sa_handler = sighandler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = SA_RESETHAND;
    for(i = 0; i < sizeof(sigs) / sizeof(sigs[0]); ++i) {
        sigaction(sigs[i], &sa, NULL);
    }
}

然后，我们编译出动态库：

1
2
3
4
[root@a896c4eb1fc4 gcov]# gcc -shared -fPIC preload.c -o libpreload.so -lgcov
[root@a896c4eb1fc4 gcov]# ls
a.out  gcov.c  lib.c  lib.gcno  lib.o  preload.c  libpreload.so
[root@a896c4eb1fc4 gcov]#

此时，我们在编译可执行文件的时候，链接一下这个库：

1
[root@a896c4eb1fc4 gcov]# gcc lib.o gcov.c -L. -lgcov -lpreload

执行可执行文件后终止它：

1
2
3
4
5
[root@a896c4eb1fc4 gcov]# ./a.out
^C
[root@a896c4eb1fc4 gcov]# ls
a.out  gcov.c  lib.c  lib.gcda  lib.gcno  lib.o  libpreload.so  preload.c
[root@a896c4eb1fc4 gcov]#

可以发现，会生成.gcda文件。我们现在就可以来查看覆盖率了：

1
2
3
4
5
6
[root@a896c4eb1fc4 gcov]# gcov lib.c
File 'lib.c'
Lines executed:100.00% of 10
Creating 'lib.c.gcov'

[root@a896c4eb1fc4 gcov]#

发表于
字数统计 313 字 | 阅读时长 1 分钟

PHP扩展开发中，一种高效的开发方式是，库的内核层和PHP的API层分离。例如Swoole，和PHP相关的API层放在了项目的根目录里面，和Swoole内核有关的代码放在了src目录里面。

我们在开发扩展的时候，不可避免的要去抛出异常或者Error等错误。那么，我们如何去处理库的内核代码返回的错误码呢？比如说，我们有操作系统返回的错误码ECHILD、EMFILE等等。或者还有我们自己定义的一些操作不当的错误码，例如EMISUSE。

一般遵循如下规则：操作系统返回的errno（例如EMFILE）我们抛出的是Exception这种可捕获的错误，因为这是运行时的，不确定的错误（运行时错误，即不知道这么做会不会出问题）。还有一种是使用上的错误，我们希望抛出Error, 不希望被捕获（也就是说，你这样做了，一定会错，所以没必要抛异常让你捕获了，直接让程序崩掉），我们可以让库的内核代码返回自定义的错误码EMISUSE，方便上层（例如PHP扩展层面）识别。

发表于
字数统计 503 字 | 阅读时长 1 分钟

本文基于的Swoole commit为：1e283dfa109fcb0887a46f3ba53bf67af021c931

我们来看一下Swoole分配协程栈的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Context::Context(size_t stack_size, coroutine_func_t fn, void* private_data) :
        fn_(fn), stack_size_(stack_size), private_data_(private_data)
{
    // 省略其他代码
#ifdef SW_CONTEXT_PROTECT_STACK_PAGE
    stack_ = (char*) ::mmap(0, stack_size_, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
#else
     stack_ = (char*) sw_malloc(stack_size_);
#endif
    // 省略其他代码
#ifdef SW_CONTEXT_PROTECT_STACK_PAGE
    mprotect(stack_, SwooleG.pagesize, PROT_NONE);
#endif
}

这里，我们发现，如果在编译Swoole的时候，定义了SW_CONTEXT_PROTECT_STACK_PAGE，即打算开启栈保护，那么就调用函数mmap来分配内存，否则，直接调用malloc来分配内存。

并且，如果打算开启栈保护，将会调用mprotect函数来对栈的第一页进行保护。PROT_NONE表明该内存空间不可访问。

这里，我补充一下，栈保护的意义。如果不进行保护，那么就可能会因为栈溢出攻击导致函数的返回地址被修改，从而执行一段恶意的代码。

至于为什么要特意去保护协程栈的原因如下：当我们自己去模拟栈的时候，可能会出现访问栈越界的问题。只读操作还好，如果进行了写操作，就非常的危险了，因此，栈保护工作还是十分必要的。（如果是编译器实现的栈，编译器就会帮我们完成栈保护的工作，所以我们在编程的时候，不需要去做这种保护栈的工作）

那么，这里为啥使用mmap呢？因为mmap分配的内存是按page对齐的。而mprotect是按照页来进行设置的。因此，如果栈地址没有对齐，应该先对齐之后再去调用mprotect。

当然，这里也可以调用malloc来获取一块内存，然后从malloc返回的指针开始，找到对齐的那个位置，然后再调用mprotect，代码大概如下：

1
2
3
4
5
6
stack = malloc(stack_size);
stack = (void *) (((uintptr_t) stack) & ~(pagesize - 1));

#ifdef SW_CONTEXT_PROTECT_STACK_PAGE
mprotect(stack + pagesize, pagesize, PROT_NONE);
#endif

所以，Swoole这里通过mmap来分配内存，实际上是一种简化的做法。

发表于
字数统计 726 字 | 阅读时长 2 分钟

我们知道，在PHP的世界里，如果我们要申请一块内存 ，但是没有申请到，那么就会导致fatal级别的错误。我们来测试下：

1
2
3
4
5
<?php

ini_set('memory_limit','1M');

$str = str_repeat('a', 2 * 1024 * 1024);

执行结果如下：

1
2
3
4
5
[root@a896c4eb1fc4 library]# php oom.php
PHP Fatal error:  Allowed memory size of 2097152 bytes exhausted at /root/php-src/Zend/zend_string.h:144 (tried to allocate 2097184 bytes) in /root/codeDir/phpCode/library/oom.php on line 5

Fatal error: Allowed memory size of 2097152 bytes exhausted at /root/php-src/Zend/zend_string.h:144 (tried to allocate 2097184 bytes) in /root/codeDir/phpCode/library/oom.php on line 5
[root@a896c4eb1fc4 library]#

可以看到，这里抛出了fatal的错误。

可能有小伙伴会觉得很正常，既然内存用完了，就应该报错，然后终止程序的执行才对。况且，大部分的PHP程序都是FPM的模型，就算这个PHP进程挂了，也不会影响后续的请求。但是，这对于基于CLI的常驻内存的PHP程序就是致命的了，一旦超过了内存限制，就会导致整个服务挂了，哪怕这次内存申请是很不重要的，也会导致整个VM的崩溃。比如说，我想要分配一个内存，但是不确定要分配多少，所以我只能够去尝试着分配。比如说第一次尝试分配2M，第二次尝试分配1M。然而，第一次申请的内存太多了，达到了限制，直接就是fatal了，就没有后续尝试分配1M的事情了。所以，这就会导致，我们不敢百分之百的去使用内存资源，因为一旦我们不小心申请的内存超过了限制，程序就会直接奔溃，没有任何拯救的余地。

我们来打个类似的比方，我们写一个Web服务器，我们要去accept连接，但是，这个时候返回了一个Too many open files的错误码。这个时候，我们是直接让程序exit吗？还是sleep一会儿，然后再去accept连接？显然是后者。所以，我们写长生命周期的脚本，需要把内存限制往大了开。

我们现在来看一下PHP内核是如何处理内存达到限制的情况的。重点在函数zend_mm_safe_error里面：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
static ZEND_COLD ZEND_NORETURN void zend_mm_safe_error(zend_mm_heap *heap,
	const char *format,
	size_t limit,
#if ZEND_DEBUG
	const char *filename,
	uint32_t lineno,
#endif
	size_t size)
{

	heap->overflow = 1;
	zend_try {
		zend_error_noreturn(E_ERROR,
			format,
			limit,
#if ZEND_DEBUG
			filename,
			lineno,
#endif
			size);
	} zend_catch {
	}  zend_end_try();
	heap->overflow = 0;
	zend_bailout();
	exit(1);
}

在调用str_repeat时候，如果内存不够，zend_mm_safe_error就会被调用。我们发现，在这个函数里面，调用了zend_bailout()，这就会导致PHP的执行流回到php_execute_script这个函数的zend_try里面，然后，PHP脚本退出执行。

所以，我们发现，只要有一次申请的PHP内存累积到了我们设置的限制，就没有任何拯救的余地了，进程直接退出了。

发表于
字数统计 542 字 | 阅读时长 2 分钟

在C语言里面，没有map结构，只有一个简单的数组。因此，如果我们无法实现如下的映射：

1
2
3
header["Content-Type"] = "text/html";
header["Connection"] = "close";
header["Host"] = "www.host.com";

我们只可以这样写：

1
2
3
header[1] = "text/html";
header[2] = "close";
header[3] = "www.host.com";

但是，这样写可读性太差了。

好在C语言提供了宏，我们可以这么做：

1
2
3
4
5
6
7
#define CONTENT_TYPE    1
#define CONNECTION      2
#define HOST            3

header[CONTENT_TYPE] = "text/html";
header[CONNECTION] = "close";
header[HOST] = "www.host.com";

但是这么做也有一个问题，就是map的name和value分散了。如果我们要修改或者增加新的name value，那么就容易搞错位置。

所以我们有如下技巧：

1
2
3
4
5
6
7
8
#define HTTP_HEADER_MAP(XX) \
    XX(CONTENT_TYPE, "text/html") \
    XX(CONNECTION, "close") \
    XX(HOST, "www.host.com") \

#define HTTP_HEADER_VARS_GEN(name, value) char name[] = value;
    HTTP_HEADER_MAP(HTTP_HEADER_VARS_GEN)
#undef HTTP_HEADER_VARS_GEN

我们来给一个完整的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#include <stdio.h>

#define HTTP_HEADER_MAP(XX) \
    XX(CONTENT_TYPE, "text/html") \
    XX(CONNECTION, "close") \
    XX(HOST, "www.host.com") \

enum http_header_e
{
#define HTTP_HEADER_GEN(name, value) HTTP_HEADER_##name,
    HTTP_HEADER_MAP(HTTP_HEADER_GEN)
#undef HTTP_HEADER_GEN
};

int main(int argc, char const *argv[])
{
    char *header[3];
#define HTTP_HEADER_VARS_GEN(name, value) header[HTTP_HEADER_##name] = value;
    HTTP_HEADER_MAP(HTTP_HEADER_VARS_GEN)
#undef HTTP_HEADER_VARS_GEN

    printf("%s\n", header[HTTP_HEADER_CONTENT_TYPE]);
    printf("%s\n", header[HTTP_HEADER_CONNECTION]);
    printf("%s\n", header[HTTP_HEADER_HOST]);

    return 0;
}

这个技巧的大概思路是，我们通过宏定义一个伪map，即HTTP_HEADER_MAP。这个宏我们需要传递一个XX，而这个XX就根据我们的需求，来取HTTP_HEADER_MAP里面的内容。

例如，在main函数里面，我们定义了一个HTTP_HEADER_VARS_GEN来替换XX，而HTTP_HEADER_VARS_GEN就是去取HTTP_HEADER_MAP的东西，来初始化我们的header数组。

明白了这个思想之后，我们可以定一个新的宏来生成printf代码，从而继续简化我们的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#include <stdio.h>

#define HTTP_HEADER_MAP(XX) \
    XX(CONTENT_TYPE, "text/html") \
    XX(CONNECTION, "close") \
    XX(HOST, "www.host.com") \

enum http_header_e
{
#define HTTP_HEADER_GEN(name, value) HTTP_HEADER_##name,
    HTTP_HEADER_MAP(HTTP_HEADER_GEN)
#undef HTTP_HEADER_GEN
};

int main(int argc, char const *argv[])
{
    char *header[3];
#define HTTP_HEADER_VARS_GEN(name, value) header[HTTP_HEADER_##name] = value;
    HTTP_HEADER_MAP(HTTP_HEADER_VARS_GEN)
#undef HTTP_HEADER_VARS_GEN

#define HTTP_HEADER_PRINTF_GEN(name, value) printf("%s\n", header[HTTP_HEADER_##name]);
    HTTP_HEADER_MAP(HTTP_HEADER_PRINTF_GEN)
#undef HTTP_HEADER_PRINTF_GEN

    return 0;
}

可以发现，代码非常的简洁了。

总结一下套路：

  1. 定义一个伪map
  2. 定义一个GEN宏
  3. 把这个GEN宏传递进伪map里面，从这个伪map里面取我们需要的内容

发表于
字数统计 126 字 | 阅读时长 1 分钟

PHP8增加了一个新的功能，叫做Constructor parameter promotion。它可以在初始化对象属性的时候帮我们省不少代码。在PHP7中，如果我们要初始化对象的属性，我们得这么写：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Point {
    public float $x;
    public float $y;
 
    public function __construct(
        float $x,
        float $y
    ) {
        $this->x = $x;
        $this->y = $y;
    }
}

var_dump(new Point(1, 2));

而现在，使用PHP8我们可以这么写：

1
2
3
4
5
6
7
8
9
10
<?php

class Point {
    public function __construct(
        public float $x,
        public float $y
    ) {}
}

var_dump(new Point(1, 2));