|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
C# to C++ portWe have a dll component developed in C# and used by the other projects (exe) written in C#. This component has been tested and proved to be very robust component and so we are going to re-use it in another application (very large code base) which has been already written in unmanaged C++. What is the best strategy between the following two options: 1. Write a managed C++ wrapper around the C# component and use that wrapper in our unmanaged C++ project. 2. Port the C# component completely to an unmanaged C++ component and then use it in our unmanaged C++ project. The main advantage of option 1 is that it seems much quicker and we can also benefit from .Net framework library without having to re invent the wheel or use other 3rd party libraries. The main advantage of option 2 is that we are not going to get involved in the potential problems involved in mixing managed and unmanaged codes. Does anyone have any other ideas (maybe option 3 ...) or see another pros and cons in going with either option 1 or option 2? Any help would be appreciated Luca. hi,
You are clear of the pro and con of both solutions, it's up to you or your group to valorate the best way to go depending of your resources, skills and complexity of both pieces of code -- Show quoteIgnacio Machin machin AT laceupsolutions.com "Luca" <noj***@nojunk.com> wrote in message news:eh4v94$sak$1@news-01.bur.connect.com.au... > Hi everyone, > > We have a dll component developed in C# and used by the other projects > (exe) written in C#. > This component has been tested and proved to be very robust component and > so we are going to re-use it in another application (very large code base) > which has been already written in unmanaged C++. > What is the best strategy between the following two options: > > 1. Write a managed C++ wrapper around the C# component and use that > wrapper in our unmanaged C++ project. > > 2. Port the C# component completely to an unmanaged C++ component and then > use it in our unmanaged C++ project. > > > The main advantage of option 1 is that it seems much quicker and we can > also benefit from .Net framework library without having to re invent the > wheel or use other 3rd party libraries. > > The main advantage of option 2 is that we are not going to get involved in > the potential problems involved in mixing managed and unmanaged codes. > > Does anyone have any other ideas (maybe option 3 ...) or see another pros > and cons in going with either option 1 or option 2? > > Any help would be appreciated > > Luca. > > Given that you have tested and proved robustness of the C# code, I'd write a
wrapper around it. Going with option 2 will involve a lot of testing that you have already done. Mike Ober. Show quote "Luca" <noj***@nojunk.com> wrote in message news:eh4v94$sak$1@news-01.bur.connect.com.au... > Hi everyone, > > We have a dll component developed in C# and used by the other projects > (exe) written in C#. > This component has been tested and proved to be very robust component and > so we are going to re-use it in another application (very large code base) > which has been already written in unmanaged C++. > What is the best strategy between the following two options: > > 1. Write a managed C++ wrapper around the C# component and use that > wrapper in our unmanaged C++ project. > > 2. Port the C# component completely to an unmanaged C++ component and then > use it in our unmanaged C++ project. > > > The main advantage of option 1 is that it seems much quicker and we can > also benefit from .Net framework library without having to re invent the > wheel or use other 3rd party libraries. > > The main advantage of option 2 is that we are not going to get involved in > the potential problems involved in mixing managed and unmanaged codes. > > Does anyone have any other ideas (maybe option 3 ...) or see another pros > and cons in going with either option 1 or option 2? > > Any help would be appreciated > > Luca. > > I agree with Michael. Use the C# dll via interop. Your chances of
hitting errors are much smaller. "Michael D. Ober" <ober***@.alum.mit.edu.nospam> wrote in message Additional advantages of making a C++ version are -- no runtime dependency news:uIfjyWr8GHA.1012@TK2MSFTNGP05.phx.gbl... > Given that you have tested and proved robustness of the C# code, I'd write > a wrapper around it. Going with option 2 will involve a lot of testing > that you have already done. on .NET Framework, reduced memory footprint, portablity. Also, if you have a lot of good unit tests for the C# version they will help a lot with porting. Even so, unless you are badly constrained for memory or disk space, or need cross-platform capability, I agree with wrapping the working C# component. Show quote > > Mike Ober. > > "Luca" <noj***@nojunk.com> wrote in message > news:eh4v94$sak$1@news-01.bur.connect.com.au... >> Hi everyone, >> >> We have a dll component developed in C# and used by the other projects >> (exe) written in C#. >> This component has been tested and proved to be very robust component and >> so we are going to re-use it in another application (very large code >> base) which has been already written in unmanaged C++. >> What is the best strategy between the following two options: >> >> 1. Write a managed C++ wrapper around the C# component and use that >> wrapper in our unmanaged C++ project. >> >> 2. Port the C# component completely to an unmanaged C++ component and >> then use it in our unmanaged C++ project. >> >> >> The main advantage of option 1 is that it seems much quicker and we can >> also benefit from .Net framework library without having to re invent the >> wheel or use other 3rd party libraries. >> >> The main advantage of option 2 is that we are not going to get involved >> in the potential problems involved in mixing managed and unmanaged codes. >> >> Does anyone have any other ideas (maybe option 3 ...) or see another pros >> and cons in going with either option 1 or option 2? >> >> Any help would be appreciated >> >> Luca. >> >> > > If we go with option 2 do you see any issues on performance?
i.e. does the final unmanaged C++ application runs slower if we use wrapper around C# code compare to when it calls native C++ code? Also any issue about mixing managed and un managed code (memory management)? Show quote "Ben Voigt" <rbv@nospam.nospam> wrote in message news:%23M57vqv8GHA.1188@TK2MSFTNGP05.phx.gbl... > > "Michael D. Ober" <ober***@.alum.mit.edu.nospam> wrote in message > news:uIfjyWr8GHA.1012@TK2MSFTNGP05.phx.gbl... >> Given that you have tested and proved robustness of the C# code, I'd >> write a wrapper around it. Going with option 2 will involve a lot of >> testing that you have already done. > > Additional advantages of making a C++ version are -- no runtime dependency > on .NET Framework, reduced memory footprint, portablity. > > Also, if you have a lot of good unit tests for the C# version they will > help a lot with porting. > > Even so, unless you are badly constrained for memory or disk space, or > need cross-platform capability, I agree with wrapping the working C# > component. > >> >> Mike Ober. >> >> "Luca" <noj***@nojunk.com> wrote in message >> news:eh4v94$sak$1@news-01.bur.connect.com.au... >>> Hi everyone, >>> >>> We have a dll component developed in C# and used by the other projects >>> (exe) written in C#. >>> This component has been tested and proved to be very robust component >>> and so we are going to re-use it in another application (very large code >>> base) which has been already written in unmanaged C++. >>> What is the best strategy between the following two options: >>> >>> 1. Write a managed C++ wrapper around the C# component and use that >>> wrapper in our unmanaged C++ project. >>> >>> 2. Port the C# component completely to an unmanaged C++ component and >>> then use it in our unmanaged C++ project. >>> >>> >>> The main advantage of option 1 is that it seems much quicker and we can >>> also benefit from .Net framework library without having to re invent the >>> wheel or use other 3rd party libraries. >>> >>> The main advantage of option 2 is that we are not going to get involved >>> in the potential problems involved in mixing managed and unmanaged >>> codes. >>> >>> Does anyone have any other ideas (maybe option 3 ...) or see another >>> pros and cons in going with either option 1 or option 2? >>> >>> Any help would be appreciated >>> >>> Luca. >>> >>> >> >> > > "Luca" <noj***@nojunk.com> wrote in message I think you meant option 1 - wrap the C# dll in an unmanaged wrapper.news:eh6bks$s74$1@news-01.bur.connect.com.au... > If we go with option 2 do you see any issues on performance? > i.e. does the final unmanaged C++ application runs slower if we use > wrapper around C# code compare to when it calls native C++ code? Parts of it will no doubt run slower, other parts may run faster. There's an unavoidable penalty to pay when the process first loads the CLR and JIT compiles the classes you're using. Once that's out of the way, you probably wouldn't see much difference, but that depends a great deal on exactly what the wrapped code actually does. Using the wrapping technique, the memory footprint of the resulting app will no doubt be larger - several megabytes larger. That could lead to performance issues related to paging if the machine it's running on is highly memory constrained. In short, the scenarios under which the wrapping solution gives better performance are few and far between. The scenarios under which is gives acceptable (if slightly slower) performance are far more numerous. > Sure. Don't try to delete manged memory, and don't leak unmanaged memory. > Also any issue about mixing managed and un managed code (memory > management)? As long as you keep the two straight, the two systems can coexist peacefully. -cd  |
|||||||||||||||||||||||
Other interesting topics