views:

983

answers:

1

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:

  1. Once-off migration of a v1.0 C++ source base into C# and ongoing parallel maintenance
  2. 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.
  3. 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.

+2  A: 

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.

Robert Gould