当前位置：文江博客话题详情

为什么 C++ 需要“管理”语言修改吗？

发布于 2024-07-19 08:51:12 字数 205 浏览 7 评论 0原文

为什么不能编写一个编译器来管理 C++ 代码中需要管理的内容（即使其“与 CLR 兼容”）？

也许需要一些妥协，比如在某些情况下禁止 void 指针等。但是所有这些额外的关键字等等。这些添加必须解决的问题是什么？

我对某些方面以及可能难以解决的问题有自己的想法，但如果有一个良好可靠的解释，将不胜感激！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

夏有森光若流苏 2024-07-26 08:51:12

到目前为止，我不得不不同意这些答案。

要理解的主要问题是 C++ 编译器创建的代码适合非常愚蠢的环境。即使是现代的 CPU 也不知道虚拟功能，见鬼，甚至连功能都是一个延伸。例如，CPU 实际上并不关心用于展开堆栈的异常处理代码是否位于任何函数之外。 CPU 处理指令序列，包括跳转和返回。就 CPU 而言，函数当然没有名称。

因此，支持函数概念所需的所有内容都由编译器放置在那里。例如，vtable 只是具有正确大小的数组，从 CPU 的角度来看具有正确的值。 __func__ 最终作为字符串表中的一个字节序列，其中最后一个是 00。

现在，没有任何内容表明目标环境必须是哑的。你绝对可以瞄准 JVM。同样，编译器必须填写本机未提供的内容。没有原始内存？然后分配一个大字节数组并使用它来代替。没有原始指针？只需在该大字节数组中使用整数索引即可。

主要问题是 C++ 程序在宿主环境中看起来完全无法识别。 JVM 并不傻，它知道函数，但它希望它们是类成员。它不希望他们的名称中包含 < 和 > 。你可以绕过这个，但你最终得到的基本上是名称修改。与当今的名称修饰不同，这种名称修饰并非针对 C 链接器，而是针对智能环境。因此，它的反射引擎可能会确信存在一个带有成员函数__namespace_std__for_each__arguments_int_pointer_int_pointer_function_address的类c__plus__plus，这仍然是一个很好的例子。我不想知道如果您有一个 std::map 字符串来反向迭代器会发生什么。

一般来说，相反的方法实际上要容易得多。几乎所有其他语言的抽象都可以在 C++ 中消除。垃圾收集？如今，C++ 中已经允许这样做，因此您甚至可以支持 void*。

我还没有解决的一件事是性能。在大字节数组中模拟原始内存？这不会很快，特别是如果你把双打放进去的话。你可以使用很多技巧来加快速度，但是要付出什么代价呢？您可能不会获得商业上可行的产品。事实上，您可能会使用一种将 C++ 最糟糕的部分（许多不寻常的依赖于实现的行为）与 VM 最糟糕的部分（速度慢）结合起来的语言。

I'd have to disagree with the answers so far.

The main problem to understand is that a C++ compiler creates code which is suitable for a very dumb environment. Even a modern CPU does not know about virtual functions, hell, even functions are a stretch. A CPU really doesn't care that exception handling code to unwind the stack is outside any function, for instance. CPU's deal in instruction sequences, with jumps and returns. Functions certainly do not have names as far as the CPU is concerned.

Hence, everything that's needed to support the concept of a function is put there by the compiler. E.g. vtables are just arrays of the right size, with the right values from the CPUs viewpoint. __func__ ends up as a sequence of bytes in the string table, the last one of which is 00.

Now, there's nothing that says the target environment has to be dumb. You could definitely target the JVM. Again, the compiler has to fill in what's not natively offered. No raw memory? Then allocate a big byte array and use it instead. No raw pointers? Just use integer indices into that big byte array.

The main problem is that the C++ program looks quite unrecognizable from the hosting environment. The JVM isn't dumb, it knows about functions, but it expects them to be class members. It doesn't expect them to have < and > in their name. You can circumvent this, but what you end up with is basically name mangling. And unlike name mangling today, this kind of name mangling isn't intended for C linkers but for smart environments. So, its reflection engine may become convinced that there is a class c__plus__plus with member function __namespace_std__for_each__arguments_int_pointer_int_pointer_function_address, and that's still a nice example. I don't want to know what happens if you have a std::map of strings to reverse iterators.

The other way around is actually a lot easier, in general. Pretty much all abstractions of other languages can be massaged away in C++. Garbage collection? That's already allowed in C++ today, so you could support that even for void*.

One thing I didn't address yet is performance. Emulating raw memory in a big byte array? That's not going to be fast, especially if you put doubles in them. You can play a whole lot of tricks to make it faster, but at which price? You're probably not going to get a commercially viable product. In fact, you might up with a language that combines the worst parts of C++ (lots of unusual implementation-dependent behavior) with the worst parts of a VM (slow).

回复收藏 0 原文

迷乱花海 2024-07-26 08:51:12

现有的正确代码，即根据 C++ 标准编写的代码，不得无意中改变其行为。

回复收藏 0 原文

乖乖公主 2024-07-26 08:51:12

C++/CLI 主要是作为托管代码和非托管代码之间的粘合剂。因此，您需要能够混合托管和非托管概念。您需要能够在同一代码中分配托管和非托管对象，因此无法绕过单独的关键字。

回复收藏 0 原文

素年丶 2024-07-26 08:51:12

为什么不能编译针对 CLR 的本机 C++ 代码？

是的，你猜对了，妥协太多，那就没用了。我只想举三个例子...

1.) 模板：C++ 支持它们，CLR 不支持（泛型不同）。
所以你不能在你的代码中使用STL、boost等。

2.) 多重继承：C++ 支持，CLI 不支持。
您甚至无法使用标准 iostream 类及其派生类（如 stringstream、fstream），它们继承自 istream 和 ostream。

几乎没有任何代码可以编译，您甚至无法实现标准库。

3.) 垃圾收集：
大多数 C++ 应用程序手动管理内存（使用智能指针等），CLR 具有自动内存管理功能。
因此，C++ 风格的“new”和“delete”将与“gcnew”不兼容，使得现有的 C++ 代码对于这个新编译器毫无用处。

如果您必须根除所有重要功能，甚至是标准库，并且现有代码无法编译……那么还有什么意义呢？

回复收藏 0 原文

淡淡的优雅 2024-07-26 08:51:12

首先，“简单 C++”和“托管 C++”之间的区别是有意为之的，因为 MC++ 的目的之一是在现有 C++ 代码和 CLR 之间提供桥梁。

其次，有太多 C++ 功能不适合 CLR 模型。多重继承、模板、指针算术……如果没有明确的界限，程序员注定会在编译和运行时面临神秘的错误。

回复收藏 0 原文

柒七 2024-07-26 08:51:12

我认为这是因为将托管代码功能添加到 C++ 中会使 C++ 变慢并且编译器更复杂。如此之多以至于 C++ 将失去它最初的设计目的。 C++ 的优点之一是它是一种很好用的语言，它足够低级，但又具有一定的可移植性。也许这就是 C++ 标准委员会计划让它保持这种状态的原因。无论如何，我不认为 C++ 可以完全“托管”，因为这意味着用 C++ 编写的程序需要 VM 来执行。如果是这样，为什么不直接使用 C++/CLI 呢？

回复收藏 0 原文

洋洋洒洒 2024-07-26 08:51:12

Qt 框架几乎可以做到这一点。即它有智能指针，当它们指向的对象被销毁时，它们会自动设置为空。
经过 moc（元对象编译器）解析后，它仍然是本机 C++。

回复收藏 0 原文

浅笑依然 2024-07-26 08:51:12

是的，我认为 C++ 可以变得托管。但是，.NET 需要针对 C++ 进行重写，而不是偏向 BASIC。在同一个屋檐下拥有多种语言。某些功能必须被删除。在 VB.NET 和 C++.NET 之间进行选择，最终选择了 VB.NET。有趣的是，我听说 C# 比 VB.NET 更流行（尽管我两者都不用！）。

回复收藏 0 原文

隔岸观火 2024-07-26 08:51:12

.NET CLR 要求对托管对象的引用不能存在于运行时不知道的任何地方，除非对象被固定；良好的性能要求尽可能少地固定对象。由于 .NET CLR 无法理解 C++ 中可用的所有数据结构，因此不得在此类结构中保留对托管对象的引用。可以让“普通”C++ 代码与 .NET 代码交互，而无需对 C++ 语言进行任何更改，但 C++ 代码可以保留对任何 .NET 对象的任何类型“引用”的唯一方法是拥有一些.NET 端的代码为每个对象分配某种类型的句柄，并保留与句柄关联的对象的静态表。想要操作对象的 C++ 代码必须要求 .NET 包装器对句柄标识的对象执行某些操作。添加新语法使编译器能够识别 .NET 框架需要了解的对象类型，并对它们实施必要的限制。

回复收藏 0 原文

魂归处 2024-07-26 08:51:12

首先要考虑的是
一切让c++“快”的东西都会消失。
C++ 中的完整垃圾收集系统几乎是不可能的。
因为c++你几乎可以在代码中的任何地方使用指针。
如果不直接将运行时类型信息内置到
语言系统本身。
您可以利用真正的本机性能。
模板将会消失。真正的指针将会消失。
直接访问内存已经不复存在。

必须强制执行的事项清单

1. no direct pointers(pointers will get replace with complex refernces)
2. templates (generics pay for preformance)
3. simple c-style arrays (will get wrapped with array structures)
4. programmer no longer has control of whether data is on the stack or
the heap.
5. garbage collection will be enforced(this will cause the most changes to the syntax)
6. runtime type data will get added extensively to the code.
(larger code size)
7.  inlining will become more difficult for the compiler
(no more inline key word)
8. no more inline assembly.
9. the new langauge by now will become incompatible c code.(unless you go through hoops)

first thing to consider is
every thing that makes c++ "fast" will disappear.
a full garbage collection system in c++ is next to impossible.
because c++ you can have pointer nearly anywhere in the code.
runtime type information becomes costly if not directly built into the
langauge system it self.
you can take advantage of true native performance.
template will dissappear. true pointers will dissapear.
direct access to memory is gone.

list of things that would have to be enforced

1. no direct pointers(pointers will get replace with complex refernces)
2. templates (generics pay for preformance)
3. simple c-style arrays (will get wrapped with array structures)
4. programmer no longer has control of whether data is on the stack or
the heap.
5. garbage collection will be enforced(this will cause the most changes to the syntax)
6. runtime type data will get added extensively to the code.
(larger code size)
7.  inlining will become more difficult for the compiler
(no more inline key word)
8. no more inline assembly.
9. the new langauge by now will become incompatible c code.(unless you go through hoops)

回复收藏 0 原文