将C ++集成到C＃中。建议？游戏开发。 [英] Intergrating C++ into C#. Suggestions? Game Development.
问题描述
我有一个重复出现的问题，转移到C＃，我想知道
，如果有任何C＃专家可以给我任何关于这个问题的建议。最近我已经遇到了拥有大型c ++代码库的公司，而b $ b有兴趣利用C＃开发的强大功能。但是
扔掉c ++代码不是一个选择。其中大部分是关于游戏行业的问题，其中基本C ++代码需要在像PlayStation这样的游戏上运行，你仍然希望能够/>
在PC上的开发工具中使用您的代码。你可以想象这些工具非常复杂，并且可以从受管理的
环境中获益。
如果煮沸它在这里真的是问题。让我们说我有一个c ++
级车辆。
类车辆：公共GameObject
{
public：
float m_speed;
float m_mass;
PropritaryStringType m_name;
}
系统在运行时需要此类，无法管理
在任何情况下（我都没有预见到CLR解释器的用户） >
Playstation或GameCube随时待命）。此外，很多代码还需要
来运行像3dSMax或Maya这样的工具;
但是当我构建内容时我想利用这些东西
$ C $ b在C＃中像PropertyGrid一样用于自动UI和序列化。不要提到它只需要进入C＃所以所有的PC应用程序开发都可以在那里发生
。
过去这个完成了游戏顶部构建的MFC层
代码。一般来说，你会在你的c ++库中构建一些专有的Reflection系统
，并编写一些野生的MFC UI Generator来生成代码。如果你能想象，这有许多缺点。这些UI
生成器通常不稳定，不像系统中的C＃构建
那样功能，并且通常需要数月才能构建和维护。
必须解决的主要问题之一是，只需1点即可维持代码。这段代码由很多人维护
，其中大部分甚至都没有安装VS.NET。即维护
a c＃中的并行类层次结构是不可能的。
对象成员需要以某种方式转换为属性
暴露于诸如PropertyGrid之类的控件。
能够在这些对象上调用方法也是必不可少的。我们不仅仅是推动数据，通常会在这些工具中进行某种模拟
。
我有想到了许多不同的方法来做到这一点，但没有一个是真的
" Clean"，这阻止了这个社区的许多开发者采用这种技术的方式，监禁它们MFC的世界。
必须解决的主要问题之一是，只有1点
维护代码。这段代码由很多人维护，其中大部分甚至都没有安装VS.NET。即在c＃中保持并行类层次结构是不可能的。
对象成员需要以某种方式转换为属性，以便对诸如PropertyGrid之类的控件进行曝光。 br />
能够在这些对象上调用方法也是必不可少的。我们不仅仅是推动数据，通常还会在这些工具中进行某种模拟。
我想到了很多不同的方法来做到这一点，但没有一个是真的
干净，这阻止了这个社区的许多开发者采用这种技术，将他们囚禁在MFC世界。
您是否考虑过围绕C ++代码的非常薄的MC ++包装器？
这个问题是C ++正在不断变化并快速地b / b
并且那些正在做这项工作的人不能一直坚持要求更新并行类结构。大部分时间他们都不熟悉PC开发，更不用说托管C ++了。
基本上你确保MC ++层永远都会被打破。
Daniel O''Connell [C＃MVP]" < onyxkirx @ - NOSPAM--comcast.net>在消息新闻中写道：< eu ************** @ tk2msftngp13.phx.gbl> ...其中一个必须解决的主要问题是，只需1点即可维护代码。这段代码由很多人维护，其中大部分甚至都没有安装VS.NET。即在c＃中保持并行类层次结构是不可能的。
对象成员需要以某种方式转换为属性，以便对诸如PropertyGrid之类的控件进行曝光。 br />
能够在这些对象上调用方法也是必不可少的。我们不仅仅是推动数据，通常还会在这些工具中进行某种模拟。
我想到了很多不同的方法来做到这一点，但没有一个是真的
干净，这阻止了这个社区的许多开发人员采用这项技术，将他们囚禁在MFC世界。
你考虑过吗？一个非常薄的MC ++包装器围绕你的C ++代码吗？
" Tom" <菊******** @ hotmail.com>在消息中写道
news：63 ************************** @ posting.google.c om ...这个问题是C ++正在不断变化，而且正在做这项工作的人不能不断地更新并行类结构。大部分时间他们甚至不熟悉PC开发，更不用说托管C ++了。
基本上你确保MC ++层总是被打破。
然后你运气不好。 C ++类不能直接导入C＃，
你只有pinvoke（导入C方法），MC ++和COM互操作，没有
似乎符合你的需要。对不起，但C ++是你最好的选择，你可以直接使用MC ++，这可以让你使用.NET框架并写下你的b $ * C＃中的代码，但我怀疑狮子会的份额必须是用C ++编写的
。
Daniel O''Connell [C＃MVP]" < onyxkirx @ - NOSPAM--comcast.net>在
消息新闻中写道：< eu ************** @ tk2msftngp13.phx.gbl> ...>必须解决的主要问题之一是，只有1点
>维护代码。这段代码由很多人维护
>其中大部分甚至都没有安装VS.NET。即维持
> c＃中的并行类层次结构是不可能的。
>
>对象成员需要以某种方式转换为属性
>暴露于诸如PropertyGrid之类的控件。
>
>能够在这些对象上调用方法也是必不可少的。我们是
>不只是推动数据，通常还有某种模拟
>继续使用这些工具。
>
>我想到了很多不同的方法来做到这一点，但没有一个真的是
> 干净，这阻止了这个社区中的许多开发者采用
>这项技术，将它们隐藏在MFC世界中。
您是否考虑过围绕C ++代码的非常薄的MC ++包装？
I have had a reoccurring issue with movement to C# and I was wondering
if any C# gurus can give me any suggestions to this problem. Lately I
have be running into companies with large c++ code repositories that
are interested in leveraging the power of C# development. However
Throwing away the c++ code is just not an option. Most of this is in
regards to the gaming industry where the base C++ code needs to be
run on something like a PlayStation, where you still want to be able
to use your code in Development tools on the PC. As you could imagine
these tools are VERY complex and would greatly benefit from the managed
environment.
If you boil it down here is really the problem. Let''s say I have a c++
class Vehicle.
class Vehicle:public GameObject
{
public:
float m_speed;
float m_mass;
PropritaryStringType m_name;
}
This class is needed by the system at run time which CANNOT be managed
under any circumstances (I don''t foresee a CLR interpreter for the
Playstation or GameCube any time soon). Also a lot of this code needs
to also run in tools like 3dSMax or Maya;
However when I am building content I would like to leverage the things
in C# like the PropertyGrid for automatic UI, and serialization. Not to
mention just getting it into C# so all the PC app development can
happen there.
In the past this was done with a MFC layer built on top of the game
code. In general you would build some proprietary Reflection system
into your c++ libraries and write some wild MFC UI Generator to
generate code. This has many downsides if you could imagine. These UI
generators are usually unstable and not as functional as the C# built
in systems, and usually take months to build and maintain.
One of the main issues that have to be solved is, only 1 point to
maintain the code. This code is being maintained by lot''s of people
most of which will never even have VS.NET installed. i.e. maintaining
a parallel class hierarchy in c# is out of the question.
The objects members need to somehow be converted to Properties for
exposure to controls such as the PropertyGrid.
Being able to call methods on these objects is essential too. We are
not just pushing around data there is usually some sort of simulation
going on in these tools.
I have thought of many different ways to do this, but none are really
"Clean", and this stops many developers in this community for adopting
this technology, Imprisoning them in the world of MFC.
One of the main issues that have to be solved is, only 1 point to
maintain the code. This code is being maintained by lot''s of people
most of which will never even have VS.NET installed. i.e. maintaining
a parallel class hierarchy in c# is out of the question.
The objects members need to somehow be converted to Properties for
exposure to controls such as the PropertyGrid.
Being able to call methods on these objects is essential too. We are
not just pushing around data there is usually some sort of simulation
going on in these tools.
I have thought of many different ways to do this, but none are really
"Clean", and this stops many developers in this community for adopting
this technology, Imprisoning them in the world of MFC.
Have you considered a very thin MC++ wrapper around your C++ code?
The problem with this is that the C++ is changeing constantly and
rapidly and the people that are doing this work cannot be constanly
haveing to update a parallel class structure. Most of the time they
are not even famliar with PC development, let alone Managed C++.
Basically you are insuring that the MC++ layer will always be broken.
"Daniel O''Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in message news:<eu**************@tk2msftngp13.phx.gbl>...One of the main issues that have to be solved is, only 1 point to
maintain the code. This code is being maintained by lot''s of people
most of which will never even have VS.NET installed. i.e. maintaining
a parallel class hierarchy in c# is out of the question.
The objects members need to somehow be converted to Properties for
exposure to controls such as the PropertyGrid.
Being able to call methods on these objects is essential too. We are
not just pushing around data there is usually some sort of simulation
going on in these tools.
I have thought of many different ways to do this, but none are really
"Clean", and this stops many developers in this community for adopting
this technology, Imprisoning them in the world of MFC.
Have you considered a very thin MC++ wrapper around your C++ code?
"Tom" <ju********@hotmail.com> wrote in message
news:63**************************@posting.google.c om...The problem with this is that the C++ is changeing constantly and
rapidly and the people that are doing this work cannot be constanly
haveing to update a parallel class structure. Most of the time they
are not even famliar with PC development, let alone Managed C++.
Basically you are insuring that the MC++ layer will always be broken.
Then you are out of luck. C++ classes cannot be imported directly into C#,
you only have pinvoke(importing C methods), MC++, and COM interop, none of
which seem to fit your needs. I''m sorry but C++ is your best bet, you can
use MC++ directly, which allows you to use the .NET framework and write
*SOME* of your code in C#, but I suspect the lions share will have to be
written in C++.
"Daniel O''Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:<eu**************@tk2msftngp13.phx.gbl>...> One of the main issues that have to be solved is, only 1 point to
> maintain the code. This code is being maintained by lot''s of people
> most of which will never even have VS.NET installed. i.e. maintaining
> a parallel class hierarchy in c# is out of the question.
>
> The objects members need to somehow be converted to Properties for
> exposure to controls such as the PropertyGrid.
>
> Being able to call methods on these objects is essential too. We are
> not just pushing around data there is usually some sort of simulation
> going on in these tools.
>
> I have thought of many different ways to do this, but none are really
> "Clean", and this stops many developers in this community for adopting
> this technology, Imprisoning them in the world of MFC.
Have you considered a very thin MC++ wrapper around your C++ code?
这篇关于将C ++集成到C＃中。建议？游戏开发。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
