Home/ Questions/Q 520747
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-13T08:10:39+00:00

So I’m architecting an application that does necessarily C++ work, but MFC/ATL is too

  • 0

So I’m architecting an application that does necessarily C++ work, but MFC/ATL is too messy for my liking, so I had this brilliant idea of doing all the “thinking” code in native C++ and all the pretty UI code in C#. The problem, though, is interoperability between the two of them. Before I get too carried away with this, I was wondering if this is a solved problem, and there’s a really good way to do this. Note that I don’t want to mix logic and display in the same module, as it gives rise to annoyingly high coupling.

Here’s what I have so far:

enter image description here

So tell me, can it be done better?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The easiest way to handle this is to use C++/CLI, and expose your logic as .NET types.

    It’s very easy to wrap a native C++ class in a ref class that’s usuable directly from a C# user interface.

    That being said – this was my plan, originally, in my current project. My thinking was that I’d need the native code for some of the heavy math work we typically do. I’ve found, however, that it’s been easier, faster, and nicer to just move most of my logic directly into C# (separated from the UI code, but still in a C# assembly) rather than try to implement it in C++.

    My experience has been that speed has not been an issue – unsafe C# code has nearly always managed to be as fast or faster than the equivelent C++ when tuned, and it’s easier to profile and tune the C# code.

    • 0