Forlan的专栏

为什么说是TTCN3新执行器？因为来公司时，项目组已经有一个基于内存对象模型的TTCN3执行器，就是大名鼎鼎的GTR。为什么要做个新的？因为业界都是基于语言转换模型的，为了向业界看齐，也为了后续执行器的长期演进，所以投入了几个人来预研，当然我作为一个刚来报道的新员工很幸运的加入了其中。反思这近三年的开发，总的来说项目不算成功，甚至可以说是半失败的，当然这里面有太多的原因，例如：1、技术没有得到很好的积累传承。第一代执行器的开发骨干基本没有参与进来，按照albert的说法，刚开始做的时候连执行器是如何跑的都是

<br />08年做ttcn3转换器的时候，最烦人的工作就是做端口操作的模块。<br />其实端口操作也就send、receive、trigger和check语义，其他过程调用的操作我们已经不打算做的了。<br /> <br />下面是send语法：<br />Port "." send "(" TemplateInstance ")"<br />[ to ( AddressRef | AddressRefList | all component ) ]<br /> <br />下面是receive语法：<

<br />原文见<br />http://www.cnblogs.com/vacuum/archive/2010/03/08/1681085.html<br /> <br />首先应该肯定的是，这是一篇很好的文章，尤其对C++编译速度关系的更应该值得一读。<br />针对文中提到的各种各样的方法，结合ttcn3新执行器项目面对的问题进行一次深刻思考，是有必要的。<br />文章开头首先对C++编译模式进行了介绍，并分析出为什么会比较慢的原因，相信很多人都是有共鸣的。<br />编译慢的问题在大工程中尤其明

<br />无意在博客园milo的blog中看到，<br />http://www.cnblogs.com/miloyip/archive/2010/09/17/behind_cplusplus.html<br />最开始的C++编译器，是将C++代码转换成C代码，使用C编译器来实现的。<br />这个没有具体考究，但听起来是很可信的。<br />因为，C++是从C发展起来的，也就是所谓的c with class，<br />当时C++的语言特性还是很简单的，基于语言翻译来做完全是可行且不会特复杂的。<br

<br />TO DO

<br />TTCN3是一个比较怪的语言，<br />大部分语法语义都是面向过程的，但有几个概念又很面向对象，如组件。<br />说到组件，不得不说runson关键字。<br />runson关键字可以使用于function和altstep中。<br /> <br />type component MTC<br />{<br /> ......<br />}<br />function Hello() runs on MTC<br />{<br /> ......<br />}<br /> <br />ru

<br />听到反射机制，大家第一时间想到java语言。<br />我不是写java的，但问过相关的同事，大家都说反射机制在java中使用的非常广泛。<br />java的反射机制是语言级别的，得益于字节码，编译过程中生成额外的信息能保留下来，<br />也就是牺牲了部分空间来换取可扩展性，这是很值得去做的。<br />反过来看C++，虽然网上也有很多反射机制实现的方法，但毕竟不是语言级别的，<br />所以顶多算模拟，还用的非常不爽。<br /><br />有人说，C++的RTTI（Runtime Typ

<br />ttcn3语言有类型兼容这样一个概念，主要用于赋值情况。<br />最简单就是简单类型兼容，如integer类型，<br />由于ttcn3的integer属于内建类型，但同时你可以在asn文件中重定义并加上范围限制。<br />于是，一般的asn文件定义的integer类型是非常多的，可以有数十种之多。<br />如果我们把ttcn3内建的integer看做是基类，则asn重定义的应该就是派生类了。<br /> <br />因为我们的新执行器是基于C++实现的，所以也看看C++的情况。<br

<br />我们做新执行器的时候，已经有一个很稳定的执行器在公司内广泛使用的了，<br />但我们认为，新旧执行器的实现是差之千里的，从一开始我们就没有重视旧执行器的实现，也没有最大限度的重用其模块，<br />恰恰，后来经历的几次重大重构工作，殊途同归，转了一大个圈，最后还是回到了旧执行器的基础上。<br />这样的教训值得深思，或许这就是成长代价。<br /> <br />旧执行器<br />基于内存对象模型实现，使用了ANTLR的词法语法功能，然后构造出一个完备语义的内存对象集合，具有分析、编译、链接

<br />2009年4月份，我们的TTCN3新执行器大体功能已经完成了，于是找了几个项目来试点应用。<br />应用效果不太理想，特别是对于5万行以上的脚本工程，且包括大asn文件的情况。<br />新执行器转换出来的C++代码量很大，特别是由于asn类型很多，导致hpp文件代码量大的编译速度下降严重问题。<br /> <br />当时的数据大概是这样的，大asn文件存在5千多个不同的类型（约5万行），包括简单和复杂类型，<br />平均每个类型转换后的hpp代码量，约20行，合计超过1万行的hpp文件，

TTCN3语言中组件（component）概念是很重要的，组件可以作为用例（testcase）执行的主线程，也可以作为函数（function）执行的子线程。作为子线程执行时，使用组件的start方法调用。start可以调用runson该组件上的所有function，包括不同参数个数和参数类型。我们使用C++的线程函数都知道，对函数是有要求的，不能随便一个函数都可以作为线程函数调用。当然，解决方法有很多，比较简单的是，对成员函数进行二次封装，把this作为参数传递，这样就可以很容易调用this的成员函数了。但

说说TTCN3语言的component实现以前实现TTCN3执行器的时候，老实说对标准的理解是很不透彻的，最明显的一个例子就是关于组件的使用方面。组件在TTCN3语言中是一个很重要的概念，除了runson的用例和方法外，由于端口也常常作为组件的成员属性，所以使用上是非常非常广泛的。简单来说，组件的操作包括create、start、stop、running，新标准还包括alive、kill等。同时，组件支持比较和复制实现，这对一个复杂类型来说，是一个难点。type component MTC{}testcas

关于调试器，基于内存对象的TTCN3执行器是支持的。但对于新执行器，也就是基于语言转换的版本，我们需要重头实现，工作量和难度不小。首先，TTCN3转换成C++语言来跑，那调试是基于TTCN3还是C++？从用户角度来说，当然是TTCN3了，用户根本就不会理会你转