0

I am working with C++ and found that there are different kinds of C++ such as CLR, Win32, MFC....

Besides, I found that some C++ library cab be called inside some other C# program. How can it be?

Since it is believed that C++ is faster than C# as it doesn't require a platform to run it, however, if using C++ in CLR, will it become slower as the .Net framework is required?

The question is: I wanna make a C++ library that call the windows command and return the output, and this library could be called in other C# program. Is it possible to do so? and if yes, will the C++ library required the .Net framework and run slower?

user883434
  • 717
  • 2
  • 10
  • 25

2 Answers2

5

Your confusion is understandable, but your understanding is flawed.

There's no difference between C++ and using MFC, MFC is a class framework written in C++, just like any other code you might write in C++. It's just a framework that Microsoft provides with their product.

C++/CLI (not CLR) is not really C++. It's a C++-like language that compiles to .net IL bytecode. It has many limitations, and has all the same restrictions that C# and VB.NET and other .NET languages have. It's very similar to C++, but not quite the same.

C++/CLI applications compile to .net IL bytecode, so they are no different than C# applications. In fact, pretty much any .net based language will compile down to the same bytecode, and use the same frameworks.

Whether or not C# or C++/CLI programs are "slower" is not so clear cut. All too many C++ enthusiests perpetuate the myth that managed code is slow. It's not. Some things are slow, such as running it the first time (it has to compile the code on demand), but because the .NET Jitter (just in time compiler) can optimize code for the platform it's running on, it came make the code perform better.

Of course managed code also has garbage collection, which is very convenient, but might cause issues with performance in some situations. But, this is not every situation and it's not even most situations.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291
  • Good answer. And yeah, I get CLR and CLI confused all the time :) – Seth Carnegie Aug 15 '11 at 04:27
  • but when I open a new project, the the choices in visual studio show the name "CLR Empty Project" and "CLR Console Application" – user883434 Aug 15 '11 at 06:44
  • @user883434 - And? I'm not sure what your point is. Different projects are just templates that give you a place to start, they're not different kinds of C++. – Erik Funkenbusch Aug 15 '11 at 15:53
  • @user883434 To to create a native C++ project go to the "other languages" section on the left and choose "Win32" project. – Ohad Horesh Aug 16 '11 at 05:53
  • @mystere-man just one thing, Using c++ cli it's easier to call native code than in c# (introp) – Ohad Horesh Aug 16 '11 at 07:13
  • Concerning **C++/CLI vs C#**: we ported one small program from c# to c++/cli and it ran pretty much twice as fast on C++/CLI (~2000 calculations/minute on c# vs ~3600 on c++/cli). But it has to be noted, that this might be due to the amount of arithmetic operations where c# is not that efficient (e.g. it performes automatic casts to integer on arithmetic operations, thus casting back might be also necessary, etc.). Maybe the difference is not that big, if there is mainly UI stuff to be taken care off. – Levite Nov 06 '14 at 07:24
  • @Levit - you can avoid automatic casts if you structure your statements correctly. More than likely, any performance issues you saw in c# could have been avoided.. It might be more accurate to say that c# is probably more conservative by default, and thus you have to give it more explicit instruction to make it do things in less safe ways (which perform better). – Erik Funkenbusch Nov 06 '14 at 08:25
  • @ErikFunkenbusch: See following answer to see what I mean: http://stackoverflow.com/a/941665/1680919 Sadly there is no addition (operation) for byte variables in C#, as well as for some other "small" filetypes. Which is just one example though, ... but don't get me wrong, I really like C#, just not for low level arithmetic operations ^^ – Levite Nov 06 '14 at 09:23
  • @Levit - While true, there are plenty of workarounds to solve performance issues.. and worst case you could always just import some native clr code, or c++/clr code, or even write some unsafe native code. – Erik Funkenbusch Nov 06 '14 at 16:27
  • @ErikFunkenbusch: I don't want to have a discussion in the comments here - sorry for that on my part - but maybe you could give a short concrete example on how to work around the auto-casts (which is responsible for huge performance drawbacks, on smaller-type arithmetic operations), because I definately don't know of *any* way to mitigate this (other than compiling a dll/library in e.g. C and importing that - which should really not count as point for C# ^^). Thx! – Levite Nov 12 '14 at 10:19
2

Yes, it's possible.

If you use C++/CLI, you can just include the assembly in your C# project and call the functions like normal C# code. If you write it using non-CLI C++ (Win32 and MFC are not kinds of C++, they're just libraries...) then you'll have to use P/Invoke from C# to call functions written in C++.

Yes, C++/CLI is probably a little slower than vanilla C++ for some things. But not by much. The CLR is quite fast.

Seth Carnegie
  • 73,875
  • 22
  • 181
  • 249