Is there any value in Managed C++
-
Let me preface this question with this: I work in a VB shop. We turn to VC++ when performance is a concern or the solution simply cannot be implemented in VB. Since Managed C++ will compile to a common language assembly, the same as C# and VB.net, what would the diffence be other than syntax. Has anyone found any perfomance gains with Managed C++ over C# or VB.net? Other than a programmer's preference to use C++ syntax, why would someone want to use Managed C++?
-
Let me preface this question with this: I work in a VB shop. We turn to VC++ when performance is a concern or the solution simply cannot be implemented in VB. Since Managed C++ will compile to a common language assembly, the same as C# and VB.net, what would the diffence be other than syntax. Has anyone found any perfomance gains with Managed C++ over C# or VB.net? Other than a programmer's preference to use C++ syntax, why would someone want to use Managed C++?
MC++ is currently the only language that produces optimised MSIL. It is also the only language that allows you to mix native x86 code with managed code in the same module. This, plus other cool stuff like IJW ("It Just Works") allows a far more seamless integration of your legacy native C++ codebase with your newer .NET enabled applications. cheers, Chris Maunder
-
Let me preface this question with this: I work in a VB shop. We turn to VC++ when performance is a concern or the solution simply cannot be implemented in VB. Since Managed C++ will compile to a common language assembly, the same as C# and VB.net, what would the diffence be other than syntax. Has anyone found any perfomance gains with Managed C++ over C# or VB.net? Other than a programmer's preference to use C++ syntax, why would someone want to use Managed C++?
dougm wrote: I work in a VB shop. We turn to VC++ when performance is a concern or the solution simply cannot be implemented in VB. Then, by my experience, I can say you'll stay with C# or VB.NET almost 100% of the time and will have no need for MC++. Please, don't get me wrong: VC++ IS faster than anything else (except ASM), but typical VB shops never see a noticeable performance difference between MC++ and C# apps. This put, there is something very useful in MC++ for VB shops: porting old COM components. I suppose, like most VB shops did, you have now a myriad of small ATL COM components which filled the void VB left. When you migrate from your VB 6 code to VB.NET, you’ll soon notice that COM interop has lots of pitfalls (System.Runtime.Marshal.ReleaseComObject, GAC, sn –k, and several other ugly words, deployment wizard), and you’ll learn to avoid COM interop like a plague unless there is no other option. With managed C++, I migrated from mid-sized ATL COM components (100 KLOC) to a managed DLL written in MC++ in typically one afternoon. Basically, all that was needed was rewriting the IDL as a managed class, removing some COM specific features (“hey, this is not needed anymore”) and adding some .NET specific features (“hey, we could do this stuff this way and it’s much better!”).
It's not the fall that kills you: it's the sudden stop - Down by Law, Jim Jamursch (1986)
-
Let me preface this question with this: I work in a VB shop. We turn to VC++ when performance is a concern or the solution simply cannot be implemented in VB. Since Managed C++ will compile to a common language assembly, the same as C# and VB.net, what would the diffence be other than syntax. Has anyone found any perfomance gains with Managed C++ over C# or VB.net? Other than a programmer's preference to use C++ syntax, why would someone want to use Managed C++?
If you work in a VB shop, I guess there is no value for you. However, I work in a "C++ shop", and found MC++ to be the best option for exposing our native C++ libraries to .NET. IJW rules. Also, MC++ enables mixing managed and unmanaged code, use of MI, templates, STL, and I think it is a great tool for building non-visual .NET components. However, for a typical ASP.NET + ADO.NET application C# is the way to go.
-
MC++ is currently the only language that produces optimised MSIL. It is also the only language that allows you to mix native x86 code with managed code in the same module. This, plus other cool stuff like IJW ("It Just Works") allows a far more seamless integration of your legacy native C++ codebase with your newer .NET enabled applications. cheers, Chris Maunder
Cool... Since switching to .NET most of our development has been in VB and C#. The C# development has really been just because I wanted to use it. I didn't really see a use for Managed C++ but maybe I should give it another go... For instance, I've found several occasions now where .NET didn't give me what I needed so I wrote a component in ATL COM using Visual Studio 6.0 (I switch back and forth as needed... pretty sure I could do the old COM development in .NET as well but I just haven't tried). One such occasion was using a vendor's libraries that are written in straight C++. I wasn't sure of any other way (at the time .NET was very new to me) to support it other than writing a ATL COM wrapper around it, then using the ATL COM component in our .NET project. So, you're saying I could still use these libraries directly within a Class Library created in Managed C++ and continue to get all the benefits of the .NET framework without dealing with the old-style COM wrapper?
-
Cool... Since switching to .NET most of our development has been in VB and C#. The C# development has really been just because I wanted to use it. I didn't really see a use for Managed C++ but maybe I should give it another go... For instance, I've found several occasions now where .NET didn't give me what I needed so I wrote a component in ATL COM using Visual Studio 6.0 (I switch back and forth as needed... pretty sure I could do the old COM development in .NET as well but I just haven't tried). One such occasion was using a vendor's libraries that are written in straight C++. I wasn't sure of any other way (at the time .NET was very new to me) to support it other than writing a ATL COM wrapper around it, then using the ATL COM component in our .NET project. So, you're saying I could still use these libraries directly within a Class Library created in Managed C++ and continue to get all the benefits of the .NET framework without dealing with the old-style COM wrapper?
Check out http://www.codeproject.com/managedcpp/nishijw01.asp[^], or look for IJW on MSDN. cheers, Chris Maunder
-
MC++ is currently the only language that produces optimised MSIL. It is also the only language that allows you to mix native x86 code with managed code in the same module. This, plus other cool stuff like IJW ("It Just Works") allows a far more seamless integration of your legacy native C++ codebase with your newer .NET enabled applications. cheers, Chris Maunder
Chris Maunder wrote: IJW ("It Just Works") :-D
Paul Watson
Bluegrass
Cape Town, South AfricaMacbeth muttered: I am in blood / Stepped in so far, that should I wade no more, / Returning were as tedious as go o'er DavidW wrote: You are totally mad. Nice.
-
dougm wrote: I work in a VB shop. We turn to VC++ when performance is a concern or the solution simply cannot be implemented in VB. Then, by my experience, I can say you'll stay with C# or VB.NET almost 100% of the time and will have no need for MC++. Please, don't get me wrong: VC++ IS faster than anything else (except ASM), but typical VB shops never see a noticeable performance difference between MC++ and C# apps. This put, there is something very useful in MC++ for VB shops: porting old COM components. I suppose, like most VB shops did, you have now a myriad of small ATL COM components which filled the void VB left. When you migrate from your VB 6 code to VB.NET, you’ll soon notice that COM interop has lots of pitfalls (System.Runtime.Marshal.ReleaseComObject, GAC, sn –k, and several other ugly words, deployment wizard), and you’ll learn to avoid COM interop like a plague unless there is no other option. With managed C++, I migrated from mid-sized ATL COM components (100 KLOC) to a managed DLL written in MC++ in typically one afternoon. Basically, all that was needed was rewriting the IDL as a managed class, removing some COM specific features (“hey, this is not needed anymore”) and adding some .NET specific features (“hey, we could do this stuff this way and it’s much better!”).
It's not the fall that kills you: it's the sudden stop - Down by Law, Jim Jamursch (1986)
Daniel Turini wrote: rewriting the IDL as a managed class, removing some COM specific features (“hey, this is not needed anymore”) Yes, that's the amazing practical feature of metadata.
-
Let me preface this question with this: I work in a VB shop. We turn to VC++ when performance is a concern or the solution simply cannot be implemented in VB. Since Managed C++ will compile to a common language assembly, the same as C# and VB.net, what would the diffence be other than syntax. Has anyone found any perfomance gains with Managed C++ over C# or VB.net? Other than a programmer's preference to use C++ syntax, why would someone want to use Managed C++?
MC++ is crap, it makes C++ almost as useless as VB. I have used it and found it to be a nightmare. Christian NO MATTER HOW MUCH BIG IS THE WORD SIZE ,THE DATA MUCT BE TRANSPORTED INTO THE CPU. - Vinod Sharma Anonymous wrote: OK. I read a c++ book. Or...a bit of it anyway. I'm sick of that evil looking console window. I think you are a good candidate for Visual Basic. - Nemanja Trifunovic