[DocNet]

Hi,

I know that app in C++ is faster then app in C#, but what's happend when both languages used same fw?

i need answer, is app in C++.net(CLI) faster then app in C#.net,
and is application in C++.net(CLI) slower then app in native C++?

Thanks.

This post has been edited by DocNet: 14 March 2013 - 03:01 AM

[JackOfAllTrades]

Moved to .NET Framework.

I don't use the abomination that is C++(CLI), but seeing as both are compiled to the same IL for execution by the .NET runtime, I doubt there's much -- if any -- difference.

To the second, because .NET languages are interpreted and run JIT, then natic C++ will be faster than any equivalent .NET program.

[baavgai]

Any Language.NET, that runs on the .NET framework, compiles to an intermediate "executable" that runs on top of the .NET virtual machine (CLR). It doesn't matter if you use C#, VB.NET, COBOL.NET ( yeah, they have that ) or C++.NET, the code produced is functionally the same.

C++.NET offers NO advantage over other .NET language. Additionally, it's fundamentally useless to an actual C++ programmer, because the .NET additions are a syntactic nightmare, making it distinctly different language from standard C++. It is truly a train wreck and I would recommend that anyone avoid it at all costs.

There is absolutely no excuse to use C++.NET.

[hisao jen]

baavgai, on 14 March 2013 - 05:27 AM, said:

There is absolutely no excuse to use C++.NET.

Does this include Microsoft's C++ compiler?

[baavgai]

Which one?

If you've been following along, there are at least two. One that takes the C++.NET mess and makes a .NET assembly out of it. That's the one we're talking about and that should be avoided like the plague.

The Microsoft C++ compiler, the one generates makes machine code in the traditional way... Simply, if you want to use C++ to talk to Windows natively, then it only make sense to go with the manufacturer's product. If you want to do cross-platform C++, then you should probably investigate other options. Microsoft, understandably, is not a big supporter of cross-platform.

[hisao jen]

baavgai, on 22 March 2013 - 01:44 PM, said:

Which one?

If you've been following along, there are at least two. One that takes the C++.NET mess and makes a .NET assembly out of it. That's the one we're talking about and that should be avoided like the plague.

The Microsoft C++ compiler, the one generates makes machine code in the traditional way... Simply, if you want to use C++ to talk to Windows natively, then it only make sense to go with the manufacturer's product. If you want to do cross-platform C++, then you should probably investigate other options. Microsoft, understandably, is not a big supporter of cross-platform.

In my case, I'm talking about MCSV. My Qt designer defaulted to using it over g++ and I wanted to play around with C++ some more.

[baavgai]

In the context of Qt Designer, you really aren't going to get anything out of switching from g++ to cl.exe, except for possible compatibility errors. If you can do it, it will be a configuration "challenge."

If you want to play with Visual C++, grab the express version for free and start any project other than CLR. An MFC project is probably the closest analog to Qt, but it's a completely different beast.

[Jiro_]

Quote

because the .NET additions are a syntactic nightmare, making it distinctly different language from standard C++

amen to that! .NET variables are managed objects, in which VC++ requires you to add some extra tokens in there, for example when declaring a .NET object you always have to put a '^' before it's name (see here) and you'll have to use gcnew instead of new (gcnew => garbage collector new), to indicate managed objects, furthermore a .NET boolean cannot be compared to a 'regular' C++ boolean. the compiler won't throw an error for it but the result will always be false. I like programming in both C++ and .NET but the combination of both is something I only do once. my opinion? stay away from it