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?