ILBC 规范 2

接上篇《ILBC 规范》 https://www.cnblogs.com/KSongKing/p/10354824.html ，

ILBC 的目标是跨平台跨设备。

D# / ILBC 可以编写操作系统内核层以上的各种应用，

其实除了进程调度虚拟内存文件系统外，其它的内核模块可以用 D# 编写，比如 Socket 。

D# / ILBC 的设计目标是保持简单，比如 D# 支持 Lambda 表达式，但是 LinQ 应该由库来支持，与语言无关。

另一方面， ILBC 不打算发展一个庞大的优化体系。 C++ , .Net / C# 的优化体系已经庞大复杂到成为大公司也很难承受之重了。

我们不会这么干。

ILBC 认为 “简单就是优化” 。

保持简单设计和模块化，模块化会带来一些性能损耗，这些性能损耗是合理的。

保持简单设计和模块化，对于 ILBC / D# / c3 / …… 以及应用程序都是有益的。

ILBC 的目标是建立一个基础设施平台。

就像容器（比如 docker, kubernetes），容器打算在操作系统之上建立一个基础设施平台，

我们的做法不同，

ILBC 是用语言建立一个基础设施平台。

为了避开 “优化陷阱”，我决定还是启用之前的 “ValueBox” 的想法。 ValueBox 的想法之前想过，但后来又放弃了。

ValueBox 类似 java C# 里的 “装箱” 、 “拆箱” 。

ValueBox 就是对于 int long float double char 等值类型（或者说简单类型），用一个对象（ValueBox）装起来，用于需要按照对象的方式处理的场合。

本来我之前是放弃了这个想法，觉得还是按照 C# 的 “一切都是对象” 的做法，让值类型也作为对象，继承 Object 类，然后让编译器在不需要作为对象，只是对值计算的场合把值类型对象优化回值类型（C 语言里的 int long float double char 等）。

但现在既然谈到优化陷阱，上面说的 “一切都是对象” 的架构就有点呵呵了。

这有一个问题，把值对象优化回值类型，这个优化是放在 C 中间代码里还是 InnerC 编译器里，

放在 C 中间代码是指由高级语言（D# c3 等）编译器来优化，这样高级语言编译生成的 C 中间代码里面就已经是优化过的代码，比如在值计算的地方就是 C 语言的 int long float double char 等，而不是值对象。

但这样要求高级语言的编译器都按照这个标准进行优化，不然在各高级语言写的库之间动态链接时会发生问题。

比如 D# 调用 c3 写的库的 Foo(int a) 方法， c3 做过优化，所以需要的 a 参数是一个 C 语言里的 int 类型，而 D# 未作优化，传给 Foo(int a) 的 a 参数是一个 int 对象，这就出错了，这是不安全的。

但要求高级语言的编译器都按照标准优化，这是一个比较糟糕的事情。

这会让高级语言编译器变得麻烦和做重复工作，且 ILBC 会因规则累赘而缺乏活力。

如果把优化放在 InnerC 编译器里优化，那会和我们的一些想法不符。我们希望 InnerC 是一个单纯的 C 编译器，不要把 IL 层的东西掺杂到里面。

InnerC 是一个单纯的 C 编译器，这也是 ILBC 的初衷和本意。

所以，我们采用这样的设计，值类型就是值类型，对应到 C 语言里的基础类型（int long float double char 等），值类型不是对象，也不继承 Object 类，对象是引用类型，继承 Object 类。

当需要以对象的方式来处理时，把值类型包到 ValueBox 里。

每个值类型会对应一个 ValueBox，比如 int 对应 IntBox， long 对应 LongBox， float 对应 FloatBox， double 对应 DoubleBox， char 对应 CharBox， bool 对应 BoolBox 等等。

ValueBox 的使用代码比如：

IntBox i = new IntBox( 10 ); // 10 就是 IntBox 包装的 Value

或者，

int i = 10;

IntBox iBox = new IntBox( i ); // 把 int 类型的变量 i 的值包装到 IntBox

什么时候需要把值类型包到 ValueBox 里？或者说，什么时候需要以对象的方式来处理值类型？

一般是在需要动态传递参数的时候，

比如， Foo ( object o ) 方法的 o 参数可能传入各种类型，那么可以把 o 参数声明为 object 类型，这样在 Foo() 方法内部判断 o 参数的类型，根据类型执行相关操作。

又比如，反射，通过反射调用方法，参数是通过 object [ ] 数组传入，

这 2 种情况对于参数都是以对象的方式处理，如果参数是值类型的话，就需要包装成 ValueBox 再传入。

D# / ILBC 支持值类型数组、值类型泛型容器。

值类型数组就是数组元素就是值类型，假设 int 类型占 4 个字节，那么 int [ ] 数组的每个元素占用空间也是 4 个字节，这和 C 语言是一样的。

值类型泛型容器比如 List<int> ， List<int> 的内部数组就是 int [ ] 。

值类型数组，值类型泛型容器直接存取值类型，不需要对值类型装箱。

但是要注意，比如 Dictionary<TKey, TValue> ， value 可以是值类型，但 key 需要是对象类型，因为会调用 key.GetHashCode() 方法。

所以，如果 key 是值类型，需要装箱成 ValueBox 。

比如

Dictionary < string , int > ， value 可以是值类型，

Dictionary < IntBox , object > ， key 需要是对象类型，如果是 int ，需要装箱成 IntBox

如果声明 Dictionary < int , object > ，则编译器会对 key 的类型报错，提示应声明为引用类型（对象类型）。

值类型又称简单类型，

引用类型又称对象类型，

（这有点呵呵）

编译器是依据什么检查 key 类型应为引用类型呢？

我们可以在 D# 里加入一个语法，比如， Dictionary 的定义是这样：

public class Dictionary < object TKey , TValue >

{

……

public void Add ( TKey key , TValue value )

{

int hash = key.GetHashCode() ;

……

}

可以看到， TKey 的前面加了一个 object ，这表示 TKey 的类型应该是 object 类型或者 object 的子类，

这个 object 可以换成其它的类型，比如其它的类或者接口。

这样的话，如果 TKey 被声明为值类型，比如 Dictionary < int , object > ，由于 int 不是引用类型，当然也就不是 object 或者 object 的子类，于是不满足 TKey 的类型约束，于是编译器就报错了。

如果 TKey 的前面不声明 object ，会怎么样？还是会报错。

因为在 Add ( TKey key , TValue value ) 方法里调用了 key.GetHashCode() 方法，调用方法意味着必须是引用类型（对象类型），所以编译器会要求 Dictionary 的定义里要声明 TKey 的类型，且 TKey 的类型必须是引用类型（对象类型）。

这也有点呵呵。

IntBox override（重写）了 Object 类的 GetHashCode() 方法，用于返回 IntBox 包装的 int 值的 HashCode，不过 int 类型的 GetHashCode() 方法可能是最简单的了，直接返回 int 值就可以。 ^^

String 类会 override（重写） Object 类的 Equals(object o) 方法，并且会增加一个 Equals(string s) 方法， Equals( object o ) 方法内部会调用 Equals( string s ) 方法。 Equals ( object o ) 方法先判断 o 是不是 String 类型，如果不是，则返回 false，如果是，则调用 Equals( string s ) 判断是否相等。

D# 里用 “ == ” 号比较 2 个 String 的代码会被编译器处理成调用 Equals( string s ) 方法。

除了最底层的模块用 C 编写， D# / ILBC 可以编写各个层次各个种类的软件，

用 C 写可以用 InnerC 写，只要符合 ILBC 规范， InnerC 写的代码就可以和 ILBC 程序集同质链接。

从这个意义来看， ILBC / InnerC 可以编写包括操作系统在内的各个层次各个种类的软件，

从这个意义来看， ILBC 是一个软件基础设施平台。

今天看了 C# 8.0 新特性 https://mp.weixin.qq.com/s?__biz=MzAwNTMxMzg1MA==&mid=2654074187&idx=1&sn=e0a6d9c963c3405dcae232a70434f225&chksm=80dbd11eb7ac58085d5357785cae13bbd4a3ccf92e876cd12c1f8faa9ada7629e5f8b2ff030e&mpshare=1&scene=23&srcid=#rd ，

可以看出， C# 8.0 标志着 C# 开始成为 “保姆型” 语言，而不是程序员的语言。

D# 将一直会是程序员的语言，这是 D# 的设计目标和使命。

补充一点， ValueBox 的使用小技巧，

在一段代码中， ValueBox 可以只 new 一个，然后重复使用。

ValueBox 有一个 public value 字段，就是 ValueBox 包装的值，对 value 字段赋上新值就可以重新使用了。

比如， IntBox ，有 public int value 字段，

IntBox i = new IntBox( 1 );

i.value = 2;

i.value = 3;

i.value = 4;

重复使用 ValueBox 可以减少 new ValueBox 和 GC 回收的开销。

有网友提议 D# 的名字可以叫 Dava ，这名字挺好听，挺美丽的，和女神（Diva）相近，好吧，就叫 Dava 吧， D# 又名 Dava 。

接下来我们讨论泛型原理 / 规范，

泛型在 ILBC 里和 C++ 类似，由高级语言编译器生成具体类型，

假设有一个 List<T> 类，这个类的 C 中间代码如下：

struct List<T>

{

T arr [ 20 ] ; // 20 是内部数组的初始化长度

int length = 0 ;

}

void List<T><>Add<>T ( List<T> * this , T element )

{

this -> arr [ this -> length ] = element ;

this -> length ++ ;

}

T List<T><>Get<>T ( List<T> * this , int index )

{

return this -> arr [ index ] ;

}

如果在代码中使用了

List<int> list1 = new List<int>();

List<string> list2 = new List<string>();

那么编译器会为 List<int> 生成一个具体类型 List~int 类，也会为 List<string> 生成一个 List~string 类，代码如下：

struct List~int

{

int arr [ 20 ] ; // 20 是内部数组的初始化长度

int length = 0 ;

}

void List~int<>Add<>int ( List~int * this , int element )

{

this -> arr [ this -> length ] = element ;

this -> length ++ ;

}

int List~int<>Get<>int ( List~int * this , int index )

{

return this -> arr [ index ] ;

}

struct List~string

{

string * arr [ 20 ] ; // 20 是内部数组的初始化长度

int length = 0 ;

}

void List~string<>Add<>string ( List~int * this , string * element )

{

this -> arr [ this -> length ] = element ;

this -> length ++ ;

}

int List~string<>Get<>int ( List~int * this , int index )

{

return this -> arr [ index ] ;

}

可以看出来，把泛型类型里的 List<T> 替换成具体类型（List<int>, List<string>），把 T 替换成泛型参数类型（int , string *）就是具体类型。

注意，值类型把 T 替换为值类型就可以，比如 int，引用类型要把 T 替换成引用（指针），比如 string * 。

这部分由高级语言编译器完成。

复杂一点的情况是，跨程序集的情况，假设有程序集 A , B ， A 引用了 B 里的 List<T> ，那 …… ？

这个需要把 List<T> 的 C 中间代码放在 B 的元数据文件（B.ild）里， A 引用 B.ild ，编译器会从 B.ild 中获取到 List<T> 的 C 中间代码，根据 List<T> 的 C 中间代码生成具体类型的 C 中间代码。

这好像又有点呵呵了。

不过这样看来的话，上文关于泛型对值类型和引用类型的不同处理好像没必要了。

上文举例的 Dictionary<object TKey , TValue> 要把 TKey 声明为 object ，

这其实已经没必要了。

public class Dictionary < TKey , TValue >

{

……

public void Add ( TKey key , TValue value )

{

int hash = key.GetHashCode() ;

……

}

如果在代码中写了

Dictionary< int , object > dic ;

则编译器会报错 “TKey 类型不能是值类型，应该是引用类型（对象类型），因为 Dictionary < TKey , TValue > 对 TKey 调用了方法，值类型不支持调用方法。”

假设有 class Foo<T> ，代码如下：

class Foo<T>

{

void M1 ( T t )

{

t.Add();

}

Foo<A> foo = new Foo<A>();

A a = new A();

foo.M1 ( a ) ;

A 是引用类型（对象类型），如果 A 没有 Add() 方法，编译器会报错 “泛型参数类型 A 不包含 Add() 方法。”

我们还可以把代码改成：

class Foo<T>

{

T M1 ( T t )

{

return t ++ ;

}

Foo<int> foo = new Foo<int>();

int i = 0 ;

int p = foo.M1 ( i ) ;

这可以编译通过，因为 int 支持 ++ 运算符，实际上，只要支持 ++ 运算符的类型都可以使用 Foo<T> ，或者说，只要支持 ++ 运算符的类型都可以作为 Foo<T> 的泛型参数类型 T 。

猜你喜欢