4

The app on which I work is a WinForms app written almost entirely in Visual C++ circa 2003. .NET was selected, prior to my arrival on the scene, because of the UI building framework, but the vast majority of code was developed in unmanaged land. Part of that was absolutely necessary--we do some real-time image processing on some very large data sets, use some Intel image processing libraries that need pointers to the image buffers, and we really are in that <1% of cases where performance is that critical.

The app itself was a large executable formed by linking the UI code to several static libraries, each of which corresponds to a functional subsystem--data acquisition, image processing, things like that. Since I joined, I split a couple of these subsystems into DLLs by writing managed wrappers, which we reuse in other apps, but the main app is still subtantially composed of statically-linked libraries.

My colleague and I differ substantially on whether further dvelopment should emphasize unmanaged or managed. With the exception of the case I have mentioned, there are no performance requirements dictating unmanaged code. We are solidly committed to .NET, so cross-platform is not an issue. I am of the opinion that we should favor managed unless dictated otherwise.

Last month, my colleague developed a set of classes that managed a subsystem; rather than implementing them as ref classes and adding some events to a .NET interface, he wrote a couple implementations of Observer, using gcroot to hold handles to managed clients, and allowed himself to stay in unmanaged land. This seems to me wrong, just because why write something that you can have for free? But I am wondering if I am being too rigid.

Any thoughts?

user18329
  • 156
  • 2
  • 5

2 Answers2

0

There is no single right or wrong answer, except to say you leaning towards managed and your co-worker leaning towards unmanaged is definitely wrong. Whichever you choose, you both need to be in agreement in order to not make the problem of having some code managed and some code unmanaged worse.

You said "We are solidly committed to .NET". Who is "we" here? Is it your company or you and your coworker? It sounds like your coworker is not quite so committed to .NET. If the company is committed and the coworker isn't, then someone needs to reiterate to your coworker that he is part of a team and needs to follow the company direction.

If the decision really is up to the two of you and your coworker won't budge, then you should consider acquiescing.

We have a large managed/unmanaged app as well and we would never consider doing anything in unmanaged unless we absolutely had to. The majority of the app is managed. It's much better that way. But that's my opinion, not fact.

Samuel Neff
  • 73,278
  • 17
  • 138
  • 182
0

The Zen of managed vs unmanaged programming:

Good unmanaged code will be exemplified by not having a noticeable disadvantage in memory management bugs versus equivalent managed code.

Good managed code will be exemplified by not having a noticeable disadvantage in performance versus equivalent unmanaged code.

There is nothing good about interop between the two of them ;)

ianschol
  • 586
  • 2
  • 13