我有一个中等规模的项目(回合制游戏),目前用C/C++编写.只有一个人正在努力.它将与/ clr一致,尽管我没有尝试过/ clr:pure.
我正在寻找有关将其转换为C#的整个过程的建议.
它主要是带有C++的薄单板的C(带有静态/单一类的C用于作用域).是的,它不是'真正的'OO,我一直计划首先进行C#转换,以避免在转换时产生任何转换问题.
它在路径查找模块中对STL(队列类)的使用非常有限,并且因为它是一个游戏,它也不会在DLL中的第三方声音库之外进行任何内存分配,以及加载图形位图.
我想将它转换为惯用的C#.我宁愿不讨论这是否是一个好主意,我明白不是,请让我们分开.假设我有最重要的理由.
我也完成了我的研究,并且有一个与使用反射器转换方法有关的线程.当我有机会时,我打算更深入地研究它.
还有一个付费应用程序将从C++转换为C#,如果不能像我想的那样工作,我可以看一下.
最难的部分是在WPF/Silverlight或XNA(或两者)中重写接口.每个都有利有弊,但由于字体支持,我现在倾向于WPF,因为这样我不必编写所有小部件.我可能最终会同时做两个,一个XNA快速端口和一个WPF.
有几种可能的方法,我想知道是否有人有任何这样的转换经验,以及任何建议或陷阱.
1)首先创建UI,这包括将Graphics模块保持原样,并从GDI转换为原始GDI,如XNA中的调用,以及稍后转换为WPF一个对话框.
2)首先转换内核,然后将主UI保留在C++/CLI中,在转换内容后,将一个对话框一次切换到WPF.
一个相关的问题是,是否值得按模块执行此模块,或者基本上是一次性完成,以及是否最好粗略地转换为C#并清理每一个,或者用C++清理所有内容然后转换为C#.
现在的想法是重写事件循环以使用像MFC这样的本地通用循环,然后尝试将所有内容一次转换为C#.将图形保留在C++中,看看有什么中断.之后,转移到XNA并稍后提供WPF层.最后两个步骤是任意的,我认为XNA端口会更简单,但使用WPF基本面板也可能非常简单.
我愿意接受任何有用的建议.
谢谢,拉尔夫