title: Silverlight and C++ or C++ to C# ongoing code conversion?
body: <p>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.</p>
  
  <p>For GUI portability, the classic answer is to keep the core in C++ and use Cocoa/Objective-C or WPF/C# thin layers.</p>
  
  <p>However, Silverlight complicates the choices.</p>
  
  <p>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 %).</p>
  
  <p>From what I've been able to <a href="https://silverlight.net/forums/p/5329/16244.aspx" rel="nofollow noreferrer">find so far</a>, it seems unlikely that C++/CLI will be supported in Silverlight. That leaves me with the options:</p>
  
  <ol>
  <li>Once-off migration of a v1.0 C++ source base into C# and ongoing parallel maintenance</li>
  <li>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.</li>
  <li>Architectural separation of the Silverlight version so the C++ logic remains on a server. I'm a bit uncomfortable about the performance implications.</li>
  </ol>
  
  <p>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.</p>
  
  <p>Edit:
  Looking at the range of products offered by <a href="http://www.tangiblesoftwaresolutions.com" rel="nofollow noreferrer">Tangible Software Solutions</a>, 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. </p>