Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We currently have a complex VC++ software application, which uses a library like ObjectARX to build the dll. I feel there are many features in C# like Collections, Generics, and other libraries which can be used to build the current application in a better and efficient way.

I have been thinking about it, but I am not sure on how to present it to my Supervisor and colleagues.

I would appreciate any help, to help me think in the right direction and highlight the points to bring it to the team.

Few points that I thought was;

  1. With some current examples, implementing it in C# with the features.
  2. Highlight the development time is comparatively lesser in C# than C++.
  3. Use a Design Architecture.
share|improve this question
10  
Make sure you read and understand joelonsoftware.com/articles/fog0000000069.html before you promise anything. –  aviv Jul 15 '13 at 2:23
4  
"Use a Design pattern, which will help us to maintain the application in a better way." What on earth do you mean by that? Do you think design patterns are things you buy from the store and plug into your application to make them run with fewer bugs, or something? –  djechlin Jul 15 '13 at 2:45
6  
"Highlight the development time is comparatively lesser in C# than C++." That sounds extremely suspect. It's certainly not true if your developers know C++ but don't know C#. –  djechlin Jul 15 '13 at 2:45
8  
Is the system working fine, stable? Rewriting just for the sake of rewriting is a big no-no that often spells disaster. –  MetalMikester Jul 15 '13 at 12:42
2  
Hey, it's your time. ;) Worst case scenario, you gain some experience in a different language and environment. –  MetalMikester Jul 15 '13 at 13:02
show 8 more comments

5 Answers

up vote 22 down vote accepted

Short answer

You should consider that it's a very risky and costly idea that may not give you as many benefits as you think it might.

Long answer

You should consider the following:

C++ is a language that can be used at a very high level, that is cross platform (though that depends on how much you used the VC proprietary extensions) and for which many very mature tools exist. C++11 will add even more juicy bit to handle annoying use cases.

If you're thinking about a full rewrite, don't forget that rewriting fully debugged code is time you won't be implementing any new features. If you don't have a clear benefit for using C#, this is throwing money and time through the window.

If the team knows C++, then for a long time writing code in C# will be slower despite any advantage that C# brings.

You have two option for migrating your apps : restart from scratch (and see http://joelonsoftware.com/articles/fog0000000069.html , already posted), or add new features by maintaining a mapping layer between the C++ and C# code. While C# is quite good as far as calling native code go, it's still some pretty complex code to write. If you either use P/Invoke or C++/CLI, both will force you to know much deeper detail about the platform than would be required for a pure C# solution. Also, you'll spend an awful lot of time marshalling data between managed and native code. A better option may be COM, though I hope you like ATL programming.

The biggest benefits of C# are its simplicity and garbage collector that free you from thinking about a lot of corner cases. That mean it can be developed by developers that are less hardcore than what you need for C++. In your case, your team already know C++ so those benefit are much less present. If you use unique_ptr, shared_ptr, RAII and such, much of the dangerous part of C++ can be managed. Yes, you have more options to shoot yourself in the foot, but you avoid the dangerous parts.

But still...

If you're not talking about a full rewrite, yes, it could be possible to develop some part of the application in C#. But always keep it mind the cost of the mapping layer between C++ and C#. I would recommend exporting your C# parts as COM modules and calling that from C++. Be sure it bring a real advantage. If you must constantly convert vector<> to IList<> and must constantly convert your C++ type to C# one, any speed advantage of C# will be lost. You gain most of converting to C# and .NET when everything can stay inside the CLR. Getting everything inside the CLR mean a complete rewrite of a complex application and that is dangerous proposition.

All in all, I wouldn't recommend it.

share|improve this answer
11  
Sounds like C++11 might be a better choice. You'll get some of the benefits of C# development, without the migration drawbacks. –  Robert Harvey Jul 15 '13 at 4:27
add comment

It sounds like your'e about to make a lot of really bad decisions.

Highlight the development time is comparatively lesser in C# than C++.

That sounds incredibly suspect. It's certainly not true if your team knows C++ but doesn't know C#, for instance.

I feel there are many features in C# like Collections, Generics, and other libraries which can be used to build the current application in a better and efficient way.

C++ definitely has those things and in fact generics are more facile in C++ than any other language. It sounds like you just heard somewhere that C# is better, so want to spend weeks rewriting everything into C#, then not actually be any better at doing things in C# than you are in C++. Start with STL and boost...

Use a Design pattern, which will help us to maintain the application in a better way.

You seem to have no idea what a design pattern is.

Long story short: You cannot make a sound engineering case based on hearsay. You must make it on technical knowledge.

share|improve this answer
    
RAII is quite doable in C# as well -- see IDisposable‌​. –  ikh Jul 15 '13 at 3:00
6  
@ikh: IDisposable is mostly for unmanaged resources; for managed objects, it does not guarantee that those objects get garbage collected immediately, only that they are marked for garbage collection when the class instance is disposed, which happens anyway when the object goes out of scope. The only way to simulate RIAA with a managed object is to force a garbage collection to occur, which is not really the same thing. –  Robert Harvey Jul 15 '13 at 4:21
2  
@Robert Yes, but the cases where RAII is really valuable are those which the syntactic pattern associated with IDisposable addresses. The rest is about the difference between different styles of memory management (direct vs. GC). –  Donal Fellows Jul 15 '13 at 6:30
    
Really appreciate your comments, it definitely gives me a very good idea of the same. –  JNL Jul 15 '13 at 12:32
1  
@everyone removed that line, that clearly wasn't the point. –  djechlin Jul 15 '13 at 16:29
show 3 more comments

We currently have a complex VC++ software application, which uses a library like ObjectARX to build the dll. I feel there are many features in C# like Collections, Generics, and other libraries which can be used to build the current application in a better and efficient way.

(Remark. ObjectARX is the extension API for AutoCAD. Thus, OP is asking about a domain-specific application known to require deep domain-specialized knowledge.)

Take a deep breath and ask yourself whether the complexity of the software comes from the domain (computer-aided design and computational geometry), or from the choice of language. If the complexity comes from the domain, changing language may not significantly make your job easier.

Case in point, using a dumb example: a Polygon is not the same as IList<Point2>. How would an IList know how to check for repeated points? Self-intersecting segments? Embedding a coplanar 2D polygon into a plane in the 3D space?

Occasionally, the lack of some syntactic sugar in some languages will indeed complicate domain-specific software development. A prime example is lambda function. With C++11, these essential syntactic sugar can be used to simplify and modernize the code. If this is the case, modernizing the C++ code may be a better choice than migrating to C#.

Another remark to other readers: Each release of ObjectARX for Visual Studio is tied to a specific version of Visual Studio, and is neither backward nor forward compatible. As of ObjectARX 2013, use of VS2010 SP1 is required. (Thus, OP cannot easily recommend using VS2012 unless the vendor release a new version of ObjectARX and the customer (OP's employer) upgrades to it.) http://usa.autodesk.com/adsk/servlet/item?id=12257036&siteID=123112

Fortunately, VS2010 SP1 also supports a useful subset (but not all) of the C++11 syntax. In particular the iterator for-loop would simplify newly-written code somewhat. The benefit, however, might not justify modifying old code, though.


I have been thinking about it, but I am not sure on how to present it to my Supervisor and colleagues.

The best way is to just informally ask your supervisor (ideally the software architect) for consideration. It is his/her job to keep an eye on every possibility, including platform choices, migrations and the long-term viability of the project.

If you actually find yourself more knowledgeable than your supervisor / software architect (which is highly unlikely), find another job.


I would appreciate any help, to help me think in the right direction and highlight the points to bring it to the team.

My suggestion:

Roman wasn't built in a day.

At any point in time in your hypothetical re-implementation, the application as a whole needs to be demonstratable (at least runnable and testable). Thus, it will contain parts written in VC++ and parts written in C#. If you can demonstrate that the application still works in a satisfactory way (no major bugs, issues or inefficiency), you have found a "jungle path" from the project's C++ present to the C# future.

A sample worksheet:

  • Suppose 5% of the project will be migrated to C#.
    • Which modules or components in the project would you choose to be migrated to C#?
    • How do they interoperate with the rest of the application?
    • Do you foresee any difficulties?
  • Repeat the question for 20%, 40%, 60%, 80%, and 99%.

Another important question to ask:

  • Are there other teams in the company (or paying customers) that depend on the application being C++? Will these teams agree to migrate to C# as well, or will your team be able to provide interoperability for that team?

If you have done this, present your findings to the software architect, who will then be responsible for identifying roadblocks ahead in the remaining sections of this jungle path.

If you don't know how C++ and C# can interoperate ... I suggest you close this question ASAP before a torrent of downvotes burn away your hard-earned reputation points ...

share|improve this answer
    
I liked your points, especially, If you actually find yourself more knowledgeable than your supervisor / software architect (which is highly unlikely), find another job. Well, currently I am a Developer with one year of professional experience of Software Development, so was curious to discuss the point in SE. One thing I can assure you, is this question has helped me think and consider lot of things, because of the useful comments shared, so I do not consider to close this question, as I am sure it might be helpful for other Jr.Developers too. Thanks for all the help and comments :) –  JNL Jul 15 '13 at 12:40
add comment

I have done some applications in C++ and some in C#.

Granted, C++ can be more complex than C# and C# has LINQ, garbage collection etc. However, features like Collections and Generics are also available in C++, please have a look at STL, Boost and C++11.

"Modernizing" your C++ code seems the better choice for me, e.g.

  • using containers like std::list and std::vector instead of C-arrays
  • avoiding normal pointers whenever possible and switching to std::shared_ptr etc.
  • using std::string instead of char*
  • Boost provides a library for nearly everything
  • etc.

You should avoid using both C++ and C# in your application (CLR or P/Invoke), unless it's absolutely necessary, e.g. DLL for a device is written in C++ and application has been done in C#. The mapping layer will cause you headaches.

share|improve this answer
    
Regarding the mapping/interop layer: while Microsoft itself had suggested that it is not necessary to adopt a COM-like approach (with its touted P/Invoke), I personally find that a COM-like interface approach is necessary, in order to meet the object lifetime and ownership requirements of both C++ and C#. In this regard, P/Invoke was ineffective in solving the interop problem in an object-oriented application. –  rwong Jul 16 '13 at 7:50
add comment

99 times out of 100, it's better to refactor code than to rewrite it from scratch.

As for reimplementing into another language: make damn SURE that the benefits outweigh the costs and risks, both short term and long term. FYI: as the application's size and/or complexity goes up, the chances that this decision makes sense goes down.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.