Why can't a compiler be written that manages what needs to be managed in C++ code (i.e. to make it "CLR compatible")?
为什么编写的编译器不能管理需要在C ++代码中管理的内容(即使其“兼容CLR”)?
Maybe with some compromise, like prohibiting void pointers in some situations etc. But all these extra keywords etc. What's the problem that has to be solved by these additions?
也许有一些妥协,比如在某些情况下禁止无效指针等等。但所有这些额外的关键字等。这些添加必须解决的问题是什么?
I have my thoughts about some aspects and what might be hard to solve, but a good solid explanation would be highly appreciated!
我对某些方面以及可能难以解决的问题有所了解,但我们将非常感谢一个很好的解释!
11 个解决方案
#1
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.
要理解的主要问题是C ++编译器创建的代码适用于非常愚蠢的环境。即使是现代CPU也不了解虚拟功能,地狱甚至功能都是一个延伸。例如,CPU实际上并不关心用于展开堆栈的异常处理代码是否在任何函数之外。 CPU处理指令序列,具有跳转和返回。就CPU而言,函数当然没有名称。
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.
因此,编译器会将支持函数概念所需的一切都放在那里。例如。 vtables只是正确大小的数组,从CPU角度来看具有正确的值。 __func__以字符串表中的字节序列结束,最后一个字节为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.
现在,没有任何迹象表明目标环境必须是愚蠢的。你绝对可以定位JVM。同样,编译器必须填写本机提供的内容。没有原始记忆?然后分配一个大字节数组并改为使用它。没有原始指针?只需将整数索引用于该大字节数组即可。
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.
主要问题是C ++程序看起来很难从托管环境中识别出来。 JVM并不笨,它知道函数,但它希望它们是类成员。它不希望他们的名字中有 <和> 。你可以绕过这个,但你最终得到的基本上就是名字错误。与今天的名称修改不同,这种名称修改不适用于C链接器,而是适用于智能环境。因此,它的反射引擎可能会确信存在具有成员函数__namespace_std__for_each__arguments_int_pointer_int_pointer_function_address的类c__plus__plus,这仍然是一个很好的例子。我不想知道如果你有一个字符串的std :: map来反转迭代器会发生什么。
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*.
相反,另一种方式实际上更容易。几乎所有其他语言的抽象都可以用C ++进行按摩。垃圾收集?今天C ++已经允许这样做,所以你甚至可以支持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).
我还没有提到的一件事就是表现。在大字节数组中模拟原始内存?这不会很快,特别是如果你把双打。你可以玩很多技巧来加快速度,但价格是多少?您可能无法获得商业上可行的产品。事实上,你可能会使用一种语言,它将C ++的最糟糕部分(许多不寻常的依赖于实现的行为)与VM的最差部分(慢速)相结合。
#2
Existing correct code, i.e. code written according to the C++ standard, must not change its behaviour inadvertently.
现有的正确代码,即根据C ++标准编写的代码,不得无意中改变其行为。
#3
Well C++/CLI is mostly meant to be a glue between managed and unmanaged code. As such you need to have the ability to mix mangaged an unmanaged concepts. You need to be able to allocate managed and unmanged objects in the same code, so there is no way around separate key words.
C ++ / CLI主要是托管和非托管代码之间的粘合剂。因此,您需要能够混合使用非托管概念。您需要能够在同一代码中分配托管和非托管对象,因此无法绕过单独的关键字。
#4
Why can't you compile native C++ code targetting the CLR?
为什么不能编译针对CLR的本机C ++代码?
Yes, you guessed it right, there would be too many compromises, that would make it useless. I'd like to name just three examples...
是的,你猜对了,会有太多的妥协,这会使它变得毫无用处。我只想举三个例子......
1.) Templates: C++ supports them, the CLR doesn't (generics are different). So you couldn't use the STL, boost etc. in your code.
1.)模板:C ++支持它们,CLR不支持(泛型不同)。因此,您无法在代码中使用STL,boost等。
2.) Multiple inheritance: supported in C++, not in CLI. You couldn't even use the standard iostream class and derivatives (like stringstream, fstream), which inherit both from istream and ostream.
2.)多重继承:在C ++中支持,而不是在CLI中支持。你甚至无法使用标准的iostream类和衍生物(如stringstream,fstream),它们继承了istream和ostream。
Almost none of the code out there would compile, you couldn't even implement the standard library.
几乎没有任何代码可以编译,你甚至无法实现标准库。
3.) Garbage collection: Most C++ apps manage their memory manually (using smart pointers etc.), the CLR has automatic memory management. Thus the C++ style "new" and "delete" would be incompatible with "gcnew", making existing C++ code useless for this new compiler.
3.)垃圾收集:大多数C ++应用程序手动管理内存(使用智能指针等),CLR具有自动内存管理功能。因此,C ++样式“new”和“delete”将与“gcnew”不兼容,使现有的C ++代码对这个新编译器无用。
If you'd have to root out all the important features, even the standard library, and no existing code would compile... then what's the point?
如果您必须根除所有重要功能,甚至标准库,并且没有现有代码可以编译......那么重点是什么?
#5
First of all, the distinction between "simple C++" and "managed C++" was intentional, because one of the MC++ purposes was to provide a bridge between existing C++ code and CLR.
首先,“简单C ++”和“托管C ++”之间的区别是有意的,因为MC ++的目的之一是在现有C ++代码和CLR之间提供桥梁。
Next, there's just too many C++ features that don't fit into CLR model. Multiple inheritance, templates, pointer arithmetics... Without drawing a clear line the programmers would be doomed to face cryptic errors, both at compile- and runtime.
接下来,有太多的C ++功能不适合CLR模型。多重继承,模板,指针算术...在没有画出明确界限的情况下,程序员注定要在编译和运行时面对隐秘的错误。
#6
I think this is because adding managed code features into C++ would made C++ slower and the compiler more complex. So much so that C++ would lose what it's designed for in the first place. One of the nice things of C++ is that it's a nice language to work with, it's low-level enough and yet somewhat portable. And probably that's what the C++ Standard Committee plans to made it stay that way. Anyway I do not think C++ can ever be fully "managed", because that would mean programs written in C++ needs a VM to execute. If that's the case, why not just use C++/CLI?
我认为这是因为在C ++中添加托管代码功能会使C ++变慢并且编译器更复杂。因此,C ++首先会失去它的设计目标。 C ++的一个好处是,它是一种很好用的语言,它足够低,而且有点便携。也许这就是C ++标准委员会计划让它保持这种状态的原因。无论如何,我认为C ++不能完全“管理”,因为这意味着用C ++编写的程序需要一个VM来执行。如果是这种情况,为什么不使用C ++ / CLI?
#7
Qt framework does almost that. I.e. it has smart pointers, that automatically set to null, when the object that they point to is destroyed. And still it's a native C++, after parsed by moc(meta object compiler).
Qt框架几乎就是这样。即它有智能指针,当它们指向的对象被销毁时自动设置为null。在经过moc(元对象编译器)解析之后,它仍然是原生C ++。
#8
Yes, I suppose C++ could become managed. But then .NET would need to be rewritten for C++ and not with a bias towards BASIC. With having many languages all under the same roof. Certain features have got to go. It was a choice between VB.NET or C++.NET, and VB.NET was chosen. Funny thing I hear is that C# is more popular than VB.NET (although I use neither!).
是的,我想C ++可能会被管理。但是,.NET需要为C ++重写,而不是偏向于BASIC。所有语言都在同一屋檐下。某些功能必须要去。它是VB.NET或C ++ .NET之间的选择,并选择了VB.NET。我听到的有趣的事情是C#比VB.NET更受欢迎(虽然我没有使用它!)。
#9
The .NET CLR requires that no reference to a managed object can ever exist anyplace the run-time doesn't know about except while the object is pinned; good performance requires that objects be pinned as little as possible. Since the .NET CLR cannot understand all of the data structures that are usable within C++, it's imperative that no references to managed objects ever be persisted in such structures. It would be possible to have "ordinary" C++ code interact with .NET code without any changes to the C++ language, but the only way the C++ code could keep any sort of "reference" to any .NET objects would be to have a some code on the .NET side assign each object a handle of some sort, and keep a static table of the objects associated with the handles. C++ code which wanted to manipulate the objects would then have to ask the .NET wrapper to perform some operation upon the object identified by a handle. Adding the new syntax makes it possible for the compiler to identify the kinds of objects the .NET framework will need to know about, and enforce the necessary restrictions upon them.
.NET CLR要求在运行时不知道的任何地方都不能存在对托管对象的引用,除非该对象被固定;良好的性能要求尽可能少地固定物体。由于.NET CLR无法理解C ++中可用的所有数据结构,因此必须在此类结构中不再保留对托管对象的引用。有可能让“普通”C ++代码与.NET代码交互而不需要对C ++语言进行任何更改,但C ++代码可以保留任何.NET对象的任何“引用”的唯一方法就是拥有一些.NET端的代码为每个对象分配某种句柄,并保留与句柄关联的对象的静态表。想要操纵对象的C ++代码必须要求.NET包装器对句柄标识的对象执行某些操作。添加新语法使编译器可以识别.NET框架需要了解的对象类型,并对它们强制执行必要的限制。
#10
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.
首先要考虑的是使c ++“快速”的所有东西都会消失。用c ++完整的垃圾收集系统几乎是不可能的。因为c ++你几乎可以在代码中的任何地方使用指针。运行时类型信息如果没有直接内置到语言系统中则会变得昂贵。你可以利用真正的原生表现。模板将消失。真正的指针将消失。直接访问内存消失了。
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)
#11
I agree with 5hammer ! If I left Java and other managed languages that's not for nothing : that's to have FULL control over the computer, access memory manage memory myself, have control over how the computer will run my code, integrate with C libraries (such as Lua). If I loose that flexibility, then I would just leave C++ and fall back to C, and if C becomes managed too, then I would go to assembler.
我同意5hammer!如果我将Java和其他托管语言放在一起并非一无所获:那就是完全控制计算机,自己访问内存管理内存,控制计算机如何运行我的代码,与C库(如Lua)集成。如果我放松了这种灵活性,那么我就会离开C ++并回到C,如果C也被管理,那么我会去装配。
Managed languages are the worst ones ever for all gaming platforms/complex programs as they are bounding you in some kine of sandbox with no direct access to the hardware, and are much slower than compiled languages.
对于所有游戏平台/复杂程序来说,托管语言是最糟糕的,因为它们将您绑定在一些沙箱中,无法直接访问硬件,并且比编译语言慢得多。
The main purpose of C++ had always been Performence. It's one of the best language for big Games. And without this language performences a lot of games would not exist !
C ++的主要目的始终是Performence。它是大型游戏的最佳语言之一。没有这种语言的表现,很多游戏都不会存在!
#1
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.
要理解的主要问题是C ++编译器创建的代码适用于非常愚蠢的环境。即使是现代CPU也不了解虚拟功能,地狱甚至功能都是一个延伸。例如,CPU实际上并不关心用于展开堆栈的异常处理代码是否在任何函数之外。 CPU处理指令序列,具有跳转和返回。就CPU而言,函数当然没有名称。
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.
因此,编译器会将支持函数概念所需的一切都放在那里。例如。 vtables只是正确大小的数组,从CPU角度来看具有正确的值。 __func__以字符串表中的字节序列结束,最后一个字节为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.
现在,没有任何迹象表明目标环境必须是愚蠢的。你绝对可以定位JVM。同样,编译器必须填写本机提供的内容。没有原始记忆?然后分配一个大字节数组并改为使用它。没有原始指针?只需将整数索引用于该大字节数组即可。
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.
主要问题是C ++程序看起来很难从托管环境中识别出来。 JVM并不笨,它知道函数,但它希望它们是类成员。它不希望他们的名字中有 <和> 。你可以绕过这个,但你最终得到的基本上就是名字错误。与今天的名称修改不同,这种名称修改不适用于C链接器,而是适用于智能环境。因此,它的反射引擎可能会确信存在具有成员函数__namespace_std__for_each__arguments_int_pointer_int_pointer_function_address的类c__plus__plus,这仍然是一个很好的例子。我不想知道如果你有一个字符串的std :: map来反转迭代器会发生什么。
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*.
相反,另一种方式实际上更容易。几乎所有其他语言的抽象都可以用C ++进行按摩。垃圾收集?今天C ++已经允许这样做,所以你甚至可以支持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).
我还没有提到的一件事就是表现。在大字节数组中模拟原始内存?这不会很快,特别是如果你把双打。你可以玩很多技巧来加快速度,但价格是多少?您可能无法获得商业上可行的产品。事实上,你可能会使用一种语言,它将C ++的最糟糕部分(许多不寻常的依赖于实现的行为)与VM的最差部分(慢速)相结合。
#2
Existing correct code, i.e. code written according to the C++ standard, must not change its behaviour inadvertently.
现有的正确代码,即根据C ++标准编写的代码,不得无意中改变其行为。
#3
Well C++/CLI is mostly meant to be a glue between managed and unmanaged code. As such you need to have the ability to mix mangaged an unmanaged concepts. You need to be able to allocate managed and unmanged objects in the same code, so there is no way around separate key words.
C ++ / CLI主要是托管和非托管代码之间的粘合剂。因此,您需要能够混合使用非托管概念。您需要能够在同一代码中分配托管和非托管对象,因此无法绕过单独的关键字。
#4
Why can't you compile native C++ code targetting the CLR?
为什么不能编译针对CLR的本机C ++代码?
Yes, you guessed it right, there would be too many compromises, that would make it useless. I'd like to name just three examples...
是的,你猜对了,会有太多的妥协,这会使它变得毫无用处。我只想举三个例子......
1.) Templates: C++ supports them, the CLR doesn't (generics are different). So you couldn't use the STL, boost etc. in your code.
1.)模板:C ++支持它们,CLR不支持(泛型不同)。因此,您无法在代码中使用STL,boost等。
2.) Multiple inheritance: supported in C++, not in CLI. You couldn't even use the standard iostream class and derivatives (like stringstream, fstream), which inherit both from istream and ostream.
2.)多重继承:在C ++中支持,而不是在CLI中支持。你甚至无法使用标准的iostream类和衍生物(如stringstream,fstream),它们继承了istream和ostream。
Almost none of the code out there would compile, you couldn't even implement the standard library.
几乎没有任何代码可以编译,你甚至无法实现标准库。
3.) Garbage collection: Most C++ apps manage their memory manually (using smart pointers etc.), the CLR has automatic memory management. Thus the C++ style "new" and "delete" would be incompatible with "gcnew", making existing C++ code useless for this new compiler.
3.)垃圾收集:大多数C ++应用程序手动管理内存(使用智能指针等),CLR具有自动内存管理功能。因此,C ++样式“new”和“delete”将与“gcnew”不兼容,使现有的C ++代码对这个新编译器无用。
If you'd have to root out all the important features, even the standard library, and no existing code would compile... then what's the point?
如果您必须根除所有重要功能,甚至标准库,并且没有现有代码可以编译......那么重点是什么?
#5
First of all, the distinction between "simple C++" and "managed C++" was intentional, because one of the MC++ purposes was to provide a bridge between existing C++ code and CLR.
首先,“简单C ++”和“托管C ++”之间的区别是有意的,因为MC ++的目的之一是在现有C ++代码和CLR之间提供桥梁。
Next, there's just too many C++ features that don't fit into CLR model. Multiple inheritance, templates, pointer arithmetics... Without drawing a clear line the programmers would be doomed to face cryptic errors, both at compile- and runtime.
接下来,有太多的C ++功能不适合CLR模型。多重继承,模板,指针算术...在没有画出明确界限的情况下,程序员注定要在编译和运行时面对隐秘的错误。
#6
I think this is because adding managed code features into C++ would made C++ slower and the compiler more complex. So much so that C++ would lose what it's designed for in the first place. One of the nice things of C++ is that it's a nice language to work with, it's low-level enough and yet somewhat portable. And probably that's what the C++ Standard Committee plans to made it stay that way. Anyway I do not think C++ can ever be fully "managed", because that would mean programs written in C++ needs a VM to execute. If that's the case, why not just use C++/CLI?
我认为这是因为在C ++中添加托管代码功能会使C ++变慢并且编译器更复杂。因此,C ++首先会失去它的设计目标。 C ++的一个好处是,它是一种很好用的语言,它足够低,而且有点便携。也许这就是C ++标准委员会计划让它保持这种状态的原因。无论如何,我认为C ++不能完全“管理”,因为这意味着用C ++编写的程序需要一个VM来执行。如果是这种情况,为什么不使用C ++ / CLI?
#7
Qt framework does almost that. I.e. it has smart pointers, that automatically set to null, when the object that they point to is destroyed. And still it's a native C++, after parsed by moc(meta object compiler).
Qt框架几乎就是这样。即它有智能指针,当它们指向的对象被销毁时自动设置为null。在经过moc(元对象编译器)解析之后,它仍然是原生C ++。
#8
Yes, I suppose C++ could become managed. But then .NET would need to be rewritten for C++ and not with a bias towards BASIC. With having many languages all under the same roof. Certain features have got to go. It was a choice between VB.NET or C++.NET, and VB.NET was chosen. Funny thing I hear is that C# is more popular than VB.NET (although I use neither!).
是的,我想C ++可能会被管理。但是,.NET需要为C ++重写,而不是偏向于BASIC。所有语言都在同一屋檐下。某些功能必须要去。它是VB.NET或C ++ .NET之间的选择,并选择了VB.NET。我听到的有趣的事情是C#比VB.NET更受欢迎(虽然我没有使用它!)。
#9
The .NET CLR requires that no reference to a managed object can ever exist anyplace the run-time doesn't know about except while the object is pinned; good performance requires that objects be pinned as little as possible. Since the .NET CLR cannot understand all of the data structures that are usable within C++, it's imperative that no references to managed objects ever be persisted in such structures. It would be possible to have "ordinary" C++ code interact with .NET code without any changes to the C++ language, but the only way the C++ code could keep any sort of "reference" to any .NET objects would be to have a some code on the .NET side assign each object a handle of some sort, and keep a static table of the objects associated with the handles. C++ code which wanted to manipulate the objects would then have to ask the .NET wrapper to perform some operation upon the object identified by a handle. Adding the new syntax makes it possible for the compiler to identify the kinds of objects the .NET framework will need to know about, and enforce the necessary restrictions upon them.
.NET CLR要求在运行时不知道的任何地方都不能存在对托管对象的引用,除非该对象被固定;良好的性能要求尽可能少地固定物体。由于.NET CLR无法理解C ++中可用的所有数据结构,因此必须在此类结构中不再保留对托管对象的引用。有可能让“普通”C ++代码与.NET代码交互而不需要对C ++语言进行任何更改,但C ++代码可以保留任何.NET对象的任何“引用”的唯一方法就是拥有一些.NET端的代码为每个对象分配某种句柄,并保留与句柄关联的对象的静态表。想要操纵对象的C ++代码必须要求.NET包装器对句柄标识的对象执行某些操作。添加新语法使编译器可以识别.NET框架需要了解的对象类型,并对它们强制执行必要的限制。
#10
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.
首先要考虑的是使c ++“快速”的所有东西都会消失。用c ++完整的垃圾收集系统几乎是不可能的。因为c ++你几乎可以在代码中的任何地方使用指针。运行时类型信息如果没有直接内置到语言系统中则会变得昂贵。你可以利用真正的原生表现。模板将消失。真正的指针将消失。直接访问内存消失了。
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)
#11
I agree with 5hammer ! If I left Java and other managed languages that's not for nothing : that's to have FULL control over the computer, access memory manage memory myself, have control over how the computer will run my code, integrate with C libraries (such as Lua). If I loose that flexibility, then I would just leave C++ and fall back to C, and if C becomes managed too, then I would go to assembler.
我同意5hammer!如果我将Java和其他托管语言放在一起并非一无所获:那就是完全控制计算机,自己访问内存管理内存,控制计算机如何运行我的代码,与C库(如Lua)集成。如果我放松了这种灵活性,那么我就会离开C ++并回到C,如果C也被管理,那么我会去装配。
Managed languages are the worst ones ever for all gaming platforms/complex programs as they are bounding you in some kine of sandbox with no direct access to the hardware, and are much slower than compiled languages.
对于所有游戏平台/复杂程序来说,托管语言是最糟糕的,因为它们将您绑定在一些沙箱中,无法直接访问硬件,并且比编译语言慢得多。
The main purpose of C++ had always been Performence. It's one of the best language for big Games. And without this language performences a lot of games would not exist !
C ++的主要目的始终是Performence。它是大型游戏的最佳语言之一。没有这种语言的表现,很多游戏都不会存在!