TIOBE 2022 年 3 月的编程语言排行榜显示：

https://www.tiobe.com/tiobe-index/

C 语言和 C++ 分别名列第二和第四位：

而 ABAP 编程语言名列第 42 位：

为什么这篇文章要把 C 语言和 ABAP 放在一起讲，而不是别的编程语言比如 Java 和 ABAP 呢？因为 ABAP 语言底层是基于 C/C++ 实现的，包括其关键字(比如最简单的关键字 WRITE 的 C++ 实现有 2 千多行)和虚拟机(ABAP Runtime).

SAP 内部的一群计算机科学家们发明了 ABAP 这门在企业管理软件影响极其深远的编程语言，由它实现的各种 SAP 应用帮助了全球超过 180 个国家和地区的客户们更好地运行其业务。

通过 Google 我们能搜索到一些关于这些 SAP 计算机科学家们的介绍，比如这个链接。

比如像下图这种用 kernel module 修饰的 sc_km_check_feature_2, 以及每一个 ABAP 关键字，其 C 语言的实现代码在 SAP 内部的 Netweaver 系统可以查看到，但是在客户系统上，则是以二进制目标文件的形式存储，无法查看源代码。

本文的目的是希望通过 C 语言和 ABAP 编译过程的一些介绍，加深 ABAP 开发人员们对这门语言的理解。

用 C 语言写个 Hello World 程序，另存为 study.c:

用命令行 gcc ./study.c --verbose 进行编译，参数 verbose 可供我们查看编译明细。上述命令行在我的 Ubuntu 系统上产生一串长长的输出：

我们可以一步步分析。首先用参数 -E 查看预处理生成的目标文件 study.i:

gcc -E study.c -o study.i

可以看到源代码文件只有 78 字节，编译预处理后生成的输出文件有 17116 字节。

为什么膨胀了这么多？原因是因为我源代码文件的第一行，#include<stdio.h> 被预处理器替换成了 stdio.h 的实际内容，而 stdio.h 里如果又存在 #include 其他文件的声明，这个替换过程会递归执行。因此直到 study.i 的末尾部分，我们才能看到在 study.c 里书写的源代码部分。

源代码文件 study.c 里的第一行语句 #include<stdio.h>, 请大家记住，后面讲 ABAP 还会提到。

用命令行 gcc -S 可以查看 study.c 编译后生成的汇编代码：

下面我们来聊聊 ABAP.

SAP note 1230076 Generation of ABAP loads: Tips for the analysis 介绍了一个工具程序：RSDEPEND。这个 note 提到，一个即便看起来最简单的 ABAP Hello World 报表，其实也依赖于许多标准的 Repository 对象，这些依赖我们假定称其为 A,B,C.

假设 A,B,C 其中有任何一个有改动产生，比如 A 是一个 include 程序，里面使用到了一个 DDIC 结构，在某个时刻，系统导入了一个传输请求(Transport Request), 里面包含了针对这个 DDIC 结构的更改，那么此时这个最简单的 Hello World 报表的 load 就成为了 obsolete 状态。在重新执行该报表之前，ABAP Runtime(中文译成 ABAP 运行时)会自动做一个 load invalidation 操作，生成一个最新版本的 load.

什么是 ABAP load？看 ABAP help 里的官方定义：

In the ABAP environment, a load describes a binary representation of a repository object which is optimized for fast access, in the memory or on the database.

翻译成中文：ABAP load 是 Repository 对象的二进制表现形式，针对 ABAP 环境的快速访问而做过特别优化，可以存储在数据库表中或者加载于内存里。

我们用一个实际的例子来理解 ABAP 报表激活和运行时发生的事情。

创建一张非常简单的透明表 ZLOADTEST：

写一个简单的报表，命名 为 ZTESTLOAD.报表的源代码以压缩的格式存储在表 REPOSRC 的 DATA 字段里。

测试报表的源代码很简单，把表里的数据全部读取出来：

激活这个简单的报表(是的，在 ABAP 世界里，我们习惯说激活，而不是编译）。激活后生成的 ABAP load 存储在表 REPOLOAD 的字段 LDATA 和 QDATA 里。

这两个字段存储的内容就是前面 ABAP help 提到的 ABAP load 在数据库表中的存储形式。

菜单 Goto->Navigate to->Switch to Classic Debugger:

Goto->System Areas->Internal Information:

在 System Area 区域输入 CONT，就能在下图的 NAME 列看到 ABAP load 里包含的指令。当然同开源的 JVM 不同，JVM 字节码指令集在网上能够查到，而这些 ABAP load 的指令是 SAP internal 的，因此不能在这里做解释。

然后执行前面提到的工具报表 RSDEPEND, 输入参数 program name = ZTESTLOAD, 得到结果，其中测试报表的 ABAP Load 时间戳为 07:21:02, 这个报表依赖的标准 Include 有：

由此看出，每一个标准的 ABAP 报表都自动包含了这些 include.

如果开发人员显式地再包含其中任意一个，会遇到语法错误: Module %_PF_STATUS is already defined as a OUTPUT module.

大家觉得这个 <REPINI> 是不是很像前文 C 语言部分提到的 #include<stdio.h>？

下面我们再做几轮测试。

测试 1

修改透明表的描述信息，然后重新激活透明表。

执行 RSDEPEND, 可以看到只有透明表的 Last Changed 字段发生了变化，ABAP Time Stamp 和 Screen Time Stamp 都不变，这是我们期望的结果，因为我们只是修改了透明表的描述信息，并未修改结构。

再次执行测试报表 ZTESTLOAD, 用 RSDEPEND 检测，发现测试报表的 ABAP Load 时间戳没有发生变化，这说明：即使依赖的透明表的描述信息发生变化，使用了该透明表的 ABAP 报表不需要重新编译，因为透明表描述信息不需要在报表执行期使用。

测试 2

给透明表增加新的一列，再次激活。

此时通过 RSDEPEND 发现，透明表的三个时间戳全部发生了变化，如下图蓝色矩形框所示。然而测试报表 ABAP Load 本身的时间戳仍然未变，这也是合理的，因为我们给透明表里增加了新的列后，还未执行测试报表。

再次执行 ZTESTLOAD 后，这次发现它的 ABAP Load 已经被自动 invalidate 了，时间戳从 07:21:02 变成了 07:36:02。

这也解释了一个现象：有的朋友们观察到，当系统刚升完级后，或者有一批新的传输请求导入到系统后，第一次使用 SAP 应用时，系统响应速度很慢。原因其实通过前文的两个测试已经说明了：系统在花费时间去做相关 ABAP Load invalidation. 在应用依赖的这些 Load invalidation 没有结束之前，系统无法响应用户请求。

为了避免用户在第一次使用应用时长时间等待，可以使用事务码 SGEN 预先进行 Load invalidation.

总结

C/C++ 与 ABAP 有着不同的语法和各自的应用场景，然而 ABAP Kernel 和 ABAP 运行时都是基于 C/C++ 实现，因此使用 ABAP 编写的程序随处可见 C/C++ 的影子，比如 ABAP 里的 Field Symbol 和 Reference，同 C 语言里的指针用法高度相似。本文从 C 语言一个 Hello World 程序的编译过程出发，分享了 ABAP 编程语言一些基于 C/C++ 实现的技术细节。感谢阅读。