This question already has answers here:
What is the difference between ANSI/ISO C++ and C++/CLI?
(2 answers)
Closed 7 years ago.
I'm learning C++ (CLI apparently), and every time I post a question saying that I am using C++, someone jumps down my throat saying that I'm not using C++, but C++/CLI. I'm not really sure of a difference, as I am extreamely new to this, but it seems to make everyone upset. Can anyone shine some light on the differences?
As a second note, the reason I am asking this is because it was suggested that I use CLI to be able to make a method accessible to my C# project. I have everything running fine in my C++ project, through my constructor, but now I would like to be able to call those same methods from my C# project.
C++ CLI runs on the "Common Language Interface". This basically means that when it's compiled, the compiled code will end up being allot like the byte code produced via C#.
C++ CLI has a ton of extensions added to it such as Garbage Collection that do not exist in C++. C++ CLI also allows for "safe" C++ code. In this mode you're not allowed to use pointers. There's no such thing as "safe" code in C++ it's all "unsafe". C++ CLI can be nice for interfacing .NET code and C++ libraries, but besides that, I haven't found a use for it.
The Wikipedia page has a good overview: http://en.wikipedia.org/wiki/C%2B%2B/CLI
And yes, they are right to jump on you for being able to program in C++ CLI will not allow you to program in C++....they are different enough that you cant just mix them.
AFAIK, C++ CLI allows you to have access to the .net framework.
It offers some garbage collection and few other specific features not on C++
C++ runs directly as binary complied for your hardware. C++ cli is a c++ extension that is used to interface with the MS common language runtime. It complies to IL normally and is executed inside the .net runtime. There are numerous differences between the two some of the major ones being garbage collection and how inheritance and interfaces work.
The reason to use c++Cli is gain the advantages of using the hundreds of classes provided to you by the framework. These are all accessible from any CLR compliant language so some have been left to wonder why one would use c++ to access the framework, unless you are linking into some legacy code.
Related
I'm building a cross-platform mobile application and I was suggested to use OF environment and compile my application using Xcode. I'm a Mac user and I started programming few time ago (so I'm really a beginner).
I need some class to get information about position and rotation so I was thinking to have a look at some SDK such as MoSync or CMDeviceMotion in order to understand which one is the most suitable to my purpose.
I also noted here:
https://developer.apple.com/library/ios/documentation/CoreMotion/Reference/CMDeviceMotion_Class/index.html#//apple_ref/doc/c_ref/CMDeviceMotion
that CMDeviceMotion is written for Obj-C and Swift.
So I have two question:
is it possible add to the main project libraries that are not part of OF?
should I use only C/C++ class?
Thanks.
I'm not sure if stackoverflow is the right place to ask a q like this, since any answer is very much prone to subjectivity.
I don't think there's a lot of valid reasons to even try to connect "MoSync" with OF, since they are both in a way "platforms" for developing apps, supporting different languages (javascript on the first and c++ on the latter). It is possible to mix objective-c (and swift) code with c++, so you can combine CMDeviceMotion with OF.
However to answer your question: It seems that if you want to have device information you don't need to go out of the scope of openFrameworks. Take a look at the "ofxIOSCoreLocation"class of OpenFrameworks/ofxIOS. It provides means for altitude, location, direction and so forth.
It is very possible to cross Objective-C and C++ with what is called Objective-C++ (by standard .mm instead of cpp), in openFrameworks.
Limitations and features: https://en.wikipedia.org/wiki/Objective-C#Objective-C.2B.2B
You can then from the Objective-C++ class (lets say for example ofApp.h), call Objective C delegates and functions directly.
You can not embed swift like this, however you there are some methods of using objective-c middle man class.
One of our products is a C++ application - using MFC (MDI). (And we skin the application with Codejock.)
I've been asked if we could "port the application to .NET" - so it would be possible to use, e.g., C# libraries and other .NET features. I know there is something called "C++.NET" - or maybe (if I understand it right) it should be called "managed C++" now. But I don't know much about it.
My question: Is this at all possible? Could we run an MFC-application as "managed C++"? (And can an application using Codejock be run as a "managed C++" application?) There is some other threads about this, but I haven't been able to find "a definitive answer"...
I'd be very grateful for some good advice! :-)
As far as I understand, you want to keep your MFC/Codejock GUI and allow the use of .NET libraries from you application's C++ code.
This is indeed possible, but for a complete application that is currently compiled as "native" C++ it is probably not such a good idea to convert all of it to being compiled with C++/CLI. "It Just Works (IJW)" is a nice meme, but it doesn't work always :-)
We have the same situation, namely a C++/MFC/Codejock application that needs to call into .NET assemblies. This works mostly without problems:
We have C++/CLI modules that offer a native C++ DLL interface for the native C++ code to call into and that then route these call on to an assembly written in C#.
We also have C++/CLI assemblies that offer a .NET interface for the C# code and then call back into pure native modules.
It should also be possible to have a single (say, exe) project that is compiled natively and you only enable the /clr switch for selected cpp files that need managed interop. And at the end you link everything together. Since we've never mixed it that way, I can't really say anything about this approach however. What I can say for sure though is that it is possible to compile parts on a module as /clr and parts as native.
I faced a similar problem some years ago, and found that unless for trivial cases converting from un-managed to managed or reverse side was really painfull. I ended leaving the two worlds each in its side, and simply use interop to have the COM - .NET compatibility.
It was not very nice, but a lot cheaper. The conclusion that we should wait a major evolution to consider a full rewriting.
With native c++, I mean, not managed c++, not cli, not any special things from microsoft, I can:
1) get high performance
2) use existing c++ code library and engine
3) write cross platform code (for example, for ios and android)
it needn't be fully native c++, I can use managed code to do the ui things, like object-c in ios and java in android, but beside interface, can I use native c++ code?
I suggest you have a look at the presentation here: Using the Windows Runtime from C++ and especially at the comments from Herb Sutter. I quote:
Please answer this question: If I decide to write C++ GUI application
in Metro style am I forced to use all these proprietary ref, sealed,
^, Platform::String^ extensions for GUI components or not?
#Tomas: No, you are not forced to use them. We are providing two
supported ways:
1) These language extensions (C++/CX).
2) A C++ template library (WRL), see
Windows Kits\8.0\Include\winrt\wrl as Yannick mentioned. WRL is a C++
library-based solution sort of along the lines of ATL, which offers
what I think you're looking for -- template wrapper/convenience
classes and explicit smart pointers and such.
Yes you absolutely can, real native C++ is fully supported.
You do however mostly have to use the new WinRT libraries to do an user interface or system calls and although they are native code and fully callable from C++ directly the interface to them makes it very painful indeed to do so, as everything is a reference counted COM object and in addition it's not so easy to create instances of them as just calling "new" so you have to write a lot of ugly code to do so.
As the earlier answer said, microsoft provide two ways to help with this. One is via language extensions to c++ and the other is a c++ template library. Personally I consider both to be rather ugly for doing something as simple as calling an API but that's just me :)
But to answer your question, it's completely possible to write your application in real native c++. You won't need to use managed code at all for anything. But you'll probably want to use either the language extensions or the template library to make calling the API more easy.
Personally I'm hoping someone writes a wrapper for WinRT that exposes the most necessary functionality as a more usable c++ native library and then everyone can just use that from c++ instead...
I recently asked this question https://softwareengineering.stackexchange.com/questions/129076/go-instead-of-c-c-with-cgo and got some very interesting input. However there's a mistake in my question: I assumed cgo could also be used to access c++ code but that's not possible. Instead you need to use SWIG.
The go faq says "The cgo program provides the mechanism for a “foreign function interface” to allow safe calling of C libraries from Go code. SWIG extends this capability to C++ libraries. "
my question:
Is it possible to access high-level c++ frameworks such as QT with SWIG + Go and get productive? I'd like to use Go as a "scripting language" to utilize c++ libraries.
Have you any experience with go and swig? Are there pitfalls I have to be aware of?
Update/Answer: I've asked this over IRC too and I think the question is solved:
SWIG is a rather clean way of interfacing c++ code from other languages. Sadly matching the types of c++ to something like go can be very complex and in most cases you have to specify the mapping yourself. That means that SWIG is a good way to leverage an existing codebase to reuse already written algorithms. However mapping a library like Qt to go will take you ages. Mind it's surely possible but you don't want to do it.
Those of you that came here for gui programming with go might want try go-gtk or the go version of wxWidgets.
Is it possible? Yes.
Can it be done in a reasonably short period of time? No.
If you go back and look at other projects that have taken large frameworks and tried to put an abstraction layer on it, you'll find most are "incomplete". You can probably make a fairly good start and get some initial wrappers in place, but generally even the work to get the simple cases solved takes time when there is a lot of underlying code to wrap, even with automated tools (which help, but are never a complete solution). And then... you get to the nasty remaining 10% that will take you forever (ok, a really really long time at least). And then think about how it's a changing target in the first place. Qt, for example, is about to release the next major rewrite.
Generally, it's safest to stick to the framework language that the framework was designed for. Though many have language extensions within the project itself. For example, for Qt you should check out QML, which provides (among many other things) a javascript binding to Qt. Sort of. But it might meet your "scripting" requirement.
A relevant update on this issue: it is now possible to interact with C++ using cgo with this CL, which is merged for Go 1.2. It is limited, however, to C-like functions calls, and classes, methods and C++ goodies are not supported (yet, I hope).
Let me clarify what I mean by 'normal' C++ first- I'm currently reading Walter Savitch's "Problem Solving in C++". As far as I am aware this is not written specifically for Microsoft or Unix. So my question is, how does what I am learning in this book (which I am using for my universal knowledge-gaining of c++) differ from what I keep reading about CLI C++?
Is CLI C++ just what I would encounter if I used Visual C++? I'm totally confused.
C++/CLI, (Also sometimes C++/CLR) refers to a language which is positioned somewhere in between native C++, and the .NET framework.
It's usually used for applications where you need to bridge some native code (pure C++) and managed code (Like VB, C#, F#, etc).
C++/CLI is a much different beast than regular C++ though. And when people say Visual C++, the meaning can vary depending on context. Sometimes they mean C++ with the common language runtime (CLR) layer enabled, other times they mean just plain C++. It's unfortunate that there's a lot of different terminology out there, and a lot of misnomers, but what can you do?
C++ and C++/CLI differ greatly. C++/CLI is the managed .NET-version of C++, made by Microsoft to enable a layer from .NET to native code.
c++/cli is the current version of Microsoft's Visual c++ brand of tools. (There was a different design before c++/cli)
c++/cli is really two versions of c++ in one. There is a highly standardized c++ compiler and also a version of c++ that runs on the CLI virtual machine. Obviously standard c++ never runs on a VM so that determined the two in one approach to the language.
When using it you can mix unman aged and managed code together. "Unmanaged" is code compiled just like standard c++. "Managed" is code compiler to the CLI (.Net) virtually machine's bytecode. Microsoft has extensive APIs for both managed and unmanaged code. With the product you can access both APIs.
You can develop standard c++ apps with the language and tool, you just have to be careful not to used the non-standard extensions. I suggest compiling in another compiler once in a while if you are in doubt. The managed side is totally non standard and even the unmanaged side has tons of non standard extensions.
PS I'm no expert but I was curious and read about this last week. I thought your question deserved an answer. Good luck!