Is it waste of time to develop unmanaged C++ library which like .NET framework class library in design and architecture?

Question

There a lot of C++ class libraries either open source or commercial like MFC, ATL, SmartWin++, QT. but none of them has the design and the architecture and the purity of .NET framework class library. What about the idea of implementing C++ library that is like .NET framework class library and provide the developers with a wide range of features and of course the library will be unmanaged and will wrap win32 API and COM

Answer 1

Interesting question. But I believe it would be either a waste of time or not optimal to re-create the .NET BCL (base class library) for unmanaged C++. Why is that?

1. The C++ language is quite different from the .NET languages. This means that if you were to re-write the BCL for C++, you would optimally try to make the best use of C++. This would probably result in a fairly different framework design:

   • IDisposable and Close methods would not be necessary, since C++ offers deterministic freeing of releases and teardown of objects; something like using blocks, but far more generic. (The relevant C++ concepts are scopes, automatic storage, RAII, and smart pointer classes.) That is, a C++ BCL has the potential for a much more elegant design in this respect.

   • C++ templates are quite different from .NET generics. C++ also doesn't have delegates or events (even though you could probably mimick these). Reflection and run-time type and code generation also won't work easily with C++. Finally, C++ (before C++0x) doesn't support lambda functions. This means that the more modern additions to the BCL would probably have to look quite different in C++.

2. There are things in the BCL that have become obsolete, or if you designed the BCL today, it would turn out quite differently. Let's take System.Reflection. This part of the BCL was built before generics were introduced. If it was re-written from scratch today, chances are that reflection would take advantage of generics and therefore better type safety.

3. As you see, a new, C++ version of the BCL would very likely end up quite different than the .NET BCL it's based on; so you ought to wonder if it's even necessary to base such a new library on the .NET BCL at all. Do you even need to have one single framework, or is it easier in the end to develop separate libraries? One for networking, one for abstract data types, one for GUIs, one for reflection etc.

   • Separate libraries have the disadvantage that they possibly have no consistent API design. Therefore experience with one library doesn't help you at all learning another API.

   • Because of that, separate libraries can be easier to maintain. One can maintain the reflection library without having to concert each of one's actions with the GUI library maintainers, for example.

   • Separate libraries have the advantage that you can exchange one for the other if you find a cleaner, faster, or otherwise better replacement.

4. Even if someone wrote a C++ version of the BCL -- it would take much resources to maintain such a library in the long term, even more so when you consider that it should be platform-independent. Microsoft has this capacity and these resources. Would you, too?

The lure of one great library for everything is indeed the consistency of one API, and the fact that "everyone" would use it. But I think even if you wrote such a C++ BCL, you'll find it hard to reach almost every C++ programmer and convince them to your that library.