4

所以我正在开发一种编程语言，它可以编译为字节码以供 VM 执行，也可以编译为 C 作为中间语言，用于编译为本地二进制文件。我选择 C ​​是因为它足够低级且可移植，通过重用现有编译器而节省了大量的工作量，而不必为每个不同的平台及其怪异编写编译器来汇编。

但是现有的编译器也有其缺点，其中之一就是循环依赖问题。我想以一种优雅的方式（与 C/C++ 不同）解决循环依赖关系，无需笨拙的前向声明，无需使用指针和额外的间接和浪费内存，无需将声明与定义等分开......换句话说，像某些编程语言一样，让开发人员远离这个问题。

在我看来，当前 C/C++ 编译器的主要问题是即使它不是真正的未来，它们也无法“展望未来”，因为程序员的意图已经在代码中表达了，我的编译器没有这个问题，除了解析进度的某个特定点之外，它并不是不知道任何事情，它知道具有循环依赖关系的对象的大小，并且可以计算适当的偏移量等。

我已经实现了“伪造”继承，它只是对继承结构的成员进行“内联扩展”，所以我想我也可以使用相同的方法来实际伪造聚合。在最基本和最简单的例子中：

typedef struct {
    int a;
} A;

typedef struct {
    A a;
    int b;
} B;

变成：

typedef struct {
    int A_a;
    int b;
} B;

并且编译器做了一些“翻译”：

B b;
b.a.a = 7;

变成：

b.A_a = 7;

并且以同样的方式，所有结构都被折叠成一个只包含原始类型的根结构。这样，在结构中绝对不会使用预先不知道大小的类型，因此定义的顺序变得无关紧要。自然，这种混乱对用户来说是隐藏的，并且只供编译器的“眼睛看到”，而用户端保持结构化和可读性。不言而喻，但为了与常规 C/C++ 代码兼容而保留了二进制足迹，折叠结构与使用聚合或继承的常规结构是二进制相同的。

所以我的问题是：这听起来像一个好主意吗？我错过了什么可能出错的事情吗？

编辑：我的目标只是解决循环依赖的 C/C++ 相关困难，而不是“鸡或蛋”逻辑悖论。显然，两个对象不可能在不导致某种形式的无限循环的情况下相互包含。

4

1 回答 1

1

您不能安全地使用指向子结构的指针，因为您无法通过指向原始成员来获得指向“兼容类型”的指针。例如之后

struct Foo {
    short a;
    int b;
};

struct Bar {
    struct Foo foo;
};

struct Bar bar;

指针&bar.foo和&bar.foo.a具有不同的类型，不能互换使用。它们也不能在不违反严格的别名规则的情况下转换为彼此的类型，从而触发未定义的行为。

struct可以通过每次内联整个定义来避免该问题：

struct Bar {
    struct { short a; int b; } foo;
};

Now&bar.a是一个指向struct {short; int;}它的兼容类型的指针struct Foo。

（ - 类型成员和原始成员之间也可能存在填充/对齐差异struct，但我找不到这些示例。

于 2013-11-04T11:45:06.583 回答