TTCN3新执行器系列-合理映射runson语义

TTCN3是一个比较怪的语言，
大部分语法语义都是面向过程的，但有几个概念又很面向对象，如组件。
说到组件，不得不说runson关键字。
runson关键字可以使用于function和altstep中。

 

type component MTC
{
 ......
}
function Hello() runs on MTC
{
 ......
}

 

runson的function内，可以直接使用组件内定义的成员变量。

如果用C++映射，很好理解。
组件映射成类，带runson的方法映射成类的成员函数。

映射很好，但还是有点区别的。
TTCN3的组件定义，不需要声明函数，这和C++的成员方法是不一样的。

TTCN3是数据和方法分离的，
组件内定义数据，而runson的函数，是和组件定义分离的。
实际上，runson的函数是声明即定义，
所以在一个大测试套工程中，组件定义在一个模块，而runson该组件的函数，往往分布于多个模块中。

于是，根据上述的C++映射，我们很快发现了问题。
首先，TTCN3声明即定义的概念，映射成C++代码不好做，我们需要遍历完整个工程才知道有多少函数是runson某个组件上的。
其次，任一个runson函数的声明修改，将导致转换后的C++文件大范围重编译，因为组件的h文件改动导致所有定义runson函数的模块的改动。

 

我们曾经考虑过这样的改动，
将runson相同一个组件的函数，转换后的C++代码都生成到一个cpp和h文件中。
但这个方法又导致如下的问题：

1、runson函数往往很多，数以百千个是正常的，但类的成员函数个数有限制。
而且一个类引入那么多的函数也不是一件值得去做的事情。

2、代码搬迁导致TTCN3和C++映射文件不一致，这对后续的调试器开发工作都引入了技术难度。
我们更希望代码是一对一的映射的，TTCN3在那个文件实现的，C++应该生成一个对应的文件存放转换后代码。

到目前为止，恐怕不再认为runson函数就映射成类的成员函数，是一个好的方案了。

 

后续针对这个难题而重构的代码量还是蛮大的。
重构方案的灵感来自《Inside the C++ Object Model》关于编译器实现类成员函数调用的说明。

基于runson函数声明即定义的语法，我们将runson函数实现为模块的成员函数，而非组件。
组件实例作为runson函数的第一参数传入，函数内涉及组件成员变量的使用，可通过第一参数调用实现。

就这样，runson函数依赖于模块而非组件。
当runson函数声明改动，只需要重新编译链接当前模块即可。

 

这个方案的改动是可行而且值得去做的，但需要预编译器提供完备的语法和语义信息支撑。