问题
I am working on a drawing-based product where I want to produce versions for iPhone, desktop OS/X, Windows Tablets, Silveright-based browser, Windows Mobile, and Windows in that order of priority.
For GUI portability, the classic answer is to keep the core in C++ and use Cocoa/Objective-C or WPF/C# thin layers.
However, Silverlight complicates the choices.
I wouldn't have any problem migrating my code into C++/CLI and maintaining a dual code base (with some macros to fake the C++/CLI contextual keywords and some judicial search and replace for ^ and %).
From what I've been able to find so far, it seems unlikely that C++/CLI will be supported in Silverlight. That leaves me with the options:
- Once-off migration of a v1.0 C++ source base into C# and ongoing parallel maintenance
- Live porting with a tool (recommendations please!) from C++ to C# or vice-versa, which is sufficiently smooth to be part of a build process.
- Architectural separation of the Silverlight version so the C++ logic remains on a server. I'm a bit uncomfortable about the performance implications.
Can anyone suggest alternatives, provide good news on C++/CLI in Silverlight or recommend porting tools? I'm sufficiently comfortable in either language to make C++ or C# my main language for the backend provided a port is reliable.
Edit: Looking at the range of products offered by Tangible Software Solutions, their notes on the converters make it clear that converting C# to C++ is easier than the other way. That is as I expected - it raises interesting thoughts as to constraining my C++ style to be least-common-OO-denominator.
回答1:
Architectural separation of the Silverlight version so the C++ logic remains on a server. I'm a bit uncomfortable about the performance implications.
I'd do this. The performance is probably not as bad as you imagine.
来源：https://stackoverflow.com/questions/478911/silverlight-and-c-or-c-to-c-sharp-ongoing-code-conversion