I'm making a student project called "C++ Game Development". It's a card game with client and server. Client application contains few windows which I've already made with Windows Forms in Visual Studio 2013. For client/server communication I decided to use Internet Communications Engine (ICE). During Build in client's project I had errors in auto-generated code by ICE. I found that ICE doesn't support C++/CLI, only native C++ or C# (that I can't use).
So now I am at a crossroads, whether make the whole client application in native C++ (that means for ex. use MFC which I'm not familiar with) or use both native C++ and C++/CLI (put the work I've done with Windows Forms to CLR Class Library and link to it from native C++ project with entry point) which is also not trivial.
I'm trying to choose the less time-consuming option. I'm asking to help me estimate the complexity of these approaches. I like the second much more but I'm not sure it's the easiest.
It depends how much complexity is already in your GUI. If you have a hundred dialogs/controls then rewriting it in native C++ might be the wrong answer. In this case, making your GUI into a library makes more sense.
However, its probably a better option to keep your GUI as a process and build a proxy library in native C++ that passes the ICE calls onto your server. (so C++/CLI exe calls a function in a new C++ library that makes a ICE call to the server and vice-versa).
If your GUI is small, then rewriting it in a modern (and better supported that C++/CLI) system is the best thing. Qt is probably the ultimate in native GUIs nowadays (but there are alternatives such as MFC, or wxWidgets). Even in these cases, its still probably better to code your networking subsystem as a native library anyway. Then you can change your GUI and try out a load of the GUI stacks as you like, porting your game to Android or iOS with just 1 presentation layer change.
The third alternative is to choose a different comms system. Whilst RPC like ICE are nice, the 'where its at' today is web-based comms via REST services (try an embedded c++ webserver like Mongoose or NxWeb), if you need to push data back to the client, these support WebSockets, so will provide all the functionality you need. And then, you can rewrite your GUI to be HTML based!
So: put your comms in a native C++ library.
C++/CLI can use native C++ code just fine.
Stick the generated code into a "static library project" that builds without /clr. Then list that static library as a dependency of your C++/CLI DLL.
The linker will figure out the rest. The result is called a "mixed-mode assembly".
Note that your comm library may not accept managed types. That's ok, C++/CLI can perfectly well mix unmanaged data model and managed view (UI) classes.
Related
I have a fully-working audio/video application which is entirely written in Objective-C (with bits of C/C++ and GLSL).
I now need to port it to Windows and I'm wondering what my best options are. I'd like to stay in the C/C++ domain so Java is not an option.
I know that this will be a lot of work but I also want this to be good (attention to detail is very important to me, I subclassed many UI elements to suit my needs).
Currently, I think that I could either port the whole app to C++ and use Qt for the whole UI (I did some small projects with that and found it mostly ok) or I could port the application core and write two different UIs for Windows and Mac (the Mac UI is already there of course).
Has anyone of you done what I'm trying to do and can give any insight? What's the best approach and why?
I have almost zero knowledge of Objective-C and macOS UI, but on Windows I think the best C++ OO tiny and efficient wrapper around native C Win32 APIs is WTL, based on ATL.
There's a quality series on WTL on CodeProject.
In the realm of Windows-specific C++ frameworks/libraries, you may consider MFC as well (which offers good integration with Visual Studio IDE), but honestly I prefer WTL: it's kind of more lightweight than MFC.
In addition, there's the cross-platform Qt alternative you already cited in your question.
We have a lot of business logic written in cross-platform C++. We want to write cross-platform UI for our application and use this business logic to create whole cross-platfrom application.
Is it possible to expose native module purely written in C++ to react-native?
We don't want to create wrappers around C++ code in native language (Java or Objective-C). Such wrappers will add more complexity it will make debugging and investigation much harder.
I am also looking for a way to do this directly in C++ without writing JNI for Android and Obj-C for iOS. I have found the CxxNativeModule class in the react native source. See the sample implementation SampleCxxModule.
The last thing to figure out is how to register that module in C++. In the JNI for React Native Android, implementation of NativeModule says
NativeModules whose implementation is written in C++ must not provide
any Java code (so they can be reused on other platforms), and instead
should register themselves using CxxModuleWrapper.
Then implementation of CxxModuleWrapper says
This does nothing interesting, except avoid breaking existing code.
So, this may help you get started. The last thing to figure out is how to register a CxxNativeModule so that it can be used in JS.
It seems as though you would need to find the code which is os dependent and write different versions of this code for different operating systems.
Here is a link which suggests how this might be done:
How do I check OS with a preprocessor directive?
I'd doing some research to see if it's possible to convert an MFC-based Windows app to an HTML5 browser-based app. However, I'd like to keep some non-visual classes in a separate library that can be called from the browser or used by other applications, as required. Mostly this non-visual code is CObject-derived data classes that use strings, collections, etc. I'm not really familiar with the C++ Standard Library, would it be possible to post most of my existing of code to it without too many problems? Also, if I wanted to port the serialization code could I use something like the Boost serialization library as an extension to the standard library?
Are there any tools out there that would help with this type of conversion, and identify potential problems?
It is certainly possible to replace a UI layer of an application with a different UI technology. Exactly how difficult this will be will depend on how well separated the layers are in the existing application architecture (i.e. it's easier to replace the 'V' of an MVC app then an app where the model is mixed with the presentation logic)
Keeping non-visual MFC code in separate libraries (typically DLLs) is common place, but this usually implies that the application will continue to be an MFC application.
There are a few unusual things mentioned in your post:
You are talking about replacing desktop UI (MFC) with web UI ("HTML5"). This is still somewhat unusual, unless you are also transitioning to a web application, and placing the non-visual code on the server. That said, if you search on "using html5 for desktop apps" you'll find a lot of tools and discussions. For some apps, coding a UI within the constraints of a browser is still too limiting (e.g. limits on top-level window management and placement, etc.). If your goal is to have a more portable desktop application, you may want to investigate desktop UI libraries (e.g. Qt, wxWindows, etc.)
The C++ standard library and MFC string and container classes are significantly different, aside from offering some of the same general data structures. AFAIK there are no automated tools to convert from MFC to C++ standard library. Again, if your goal is portability, this is a sensible step, and you can write some wrapper classes around the C++ implementation to help adapt your code (although this can be a good opportunity to re-implement classes, or even entire libraries.)
A not-so-unusual thing is to consider using Boost libraries in addition to the standard library - they are high-quality libraries, and can save you a lot of time over rolling your own.
I currently have an old unmanaged C++ DLL using MFC. This DLL has a bunch of code which is multi-threaded and written back in 2003 using VC6. This code sadly doesn't work anymore.
I've been tasked with finding an alternative way of running this multi-threaded code so that it does function as intended. Someone before me had already rewritten it in C#, and I need to port that C# code over to VC++. I did some research and realized that I could save some time in the porting process by just porting the C# code to VC++ (using the .NET framework). But then I realized that my old MFC DLL cannot run this .NET code.
My idea is to write this multi-threaded code in a VC++ DLL (using the .NET framework) and using some form of interoperability to be able to call the functions from the old DLL to the new DLL.
I have looked into COM interoperability as well as wrapper classes. What is the best way of accomplishing this? Are there any tutorials that could help me with this task? (I've already done some extensive searching and there are a lot of tutorials using unmanaged C++ DLLs to C# DLLs, but not much that pertains to my situtation).
Just so you know, I cannot compile the old DLL with /clr as this DLL is hosted in an old Win32 application as well. Compiling with /clr causes the application to crash, or else this would have already been done.
TO CLARIFY: I'm curious as to why calling functions residing in a C# DLL from an unmanaged C++ DLL through a COM interop seems so simple compared to doing the exact same thing using a managed C++ DLL. I even have a proof-of-concept between C# and C++, but I can't for the life of me begin to understand performing the exact same task with C++. Does there happen to be just a simple tutorial for calling just one simple (let's say 'Add') function from unmanaged C++ to managed C++?
If you have a (managed) DLL, regardless of the language(s) it is written in, you need a process to run it in. If you have a native process that -- for whatever reason -- must not use the CLR, that you cannot directly use a managed DLL (any code that depends on the CLR in-process) from this process directly.
You would need a second helper process that runs the managed DLL and, for example, exposes a COM interface that the native process could call. (out of process COM server)
I have looked into COM interoperability as well as wrapper classes. What is the best way of accomplishing this?
Not sure what you mean with wrapper classes, but an out of process COM server for your managed DLL could do the trick. (Obviously, this is quite some overhand wrt. to managing the proper registration and startup/shutdown of the helper process.)
Breaking the problem up a bit (as far as I understand):
[oldish Win32 app (no! CLR)]
<- normal DLL interface -> [native/MFC DLL (no! CLR)]
<- via COM -> [stuff in a separate executable]
If this is what you are looking for, then this article (just a quick Google hit) may be helpful:
http://www.codeproject.com/KB/COM/BuildCOMServersInDotNet.aspx
For COM in general, I think any COM tutorial should cover what you are supposedly trying to do.
Is there any way to build graphical interfaces in the same rapid and easy way we could do in Visual Studio, but without .NET Framework? I'm looking to native Windows GUIs, so using Qt with Qt Creator is not an option (and it doesn't need to be cross-platform). Something with the Windows API using C++ would be great (not Delphi).
I mean, applications like WinSCP really have its GUIs written entirely by hand?
Given:
You don't want to use Qt
You want to use Win API
The natural option is MFC. It's basically quite a thin wrapper around the Win32 UI API, but VS has an MFC UI designer that will save you a lot of work (no need to manually set the co-ordinates of controls etc.).
My vote is still on Qt.
I suspect OP is really confusing "Native" with "deployable in a single binary". You can achieve this also with Qt by statically linking Qt dependencies. Contrary to popular belief, the LGPL does not prohibit this either.
Now if OP is looking for "deployable in a single super small binary" utorrent style, the answer would differ. A discussion around small binaries seems a good place to look. I would say there is a price to pay in increased development time though.
But I can't agree on Qt not being as native as say MFC.
Another excellent option is C++Builder with the VCL. This is very similar to WinForms (whose design it clearly inspired) and much more productive than MFC in my opinion.
As both Qt and MFC are wrappers around the native OS functions for managing windows and other OS utilities (that use Win32 API under the hood and look completely native) there is really no reason to consider the use of MFC over Qt, as it is not more native than Qt. Either your definition of "native" is broken or you haven't told us the whole story.
But there are a thousand reasons for considering Qt over MFC, as the latter is a complete pain to use, whereas the former is a cleanly designed, easy to use and still highly flexible library (that strives for nativity by any means possible).
The only way you might see MFC as more native is that it comes from Microsoft (the same company that developed Windows). But that doesn't make it more native. It's still a third party library. This third party worked for the same company as the party developing the Win32 API, but that doesn't make it specifically more tied to the Win32 API, as both were developed independently (and surely by different people).
Do Qt apps look and feel native under Windows?
You could also take a look at wxWidgets.
In addition to MFC, you might want to look into the Windows Template Library.