[RESOLVED] Will MFC be made a better neighbour?

Will some of the historical baggage in MFC be tidied up?

I am thinking of:

• If you use #define NOMINMAX to tame the SDK header files and allow well behaved minimum and maximum functions, you have to put three lines of declarations before MFC headers.
• The MFC object macros create member names from the class names, frustrating use of namespaces.
• Various MFC functions return BOOL, giving a compiler warning when converted to bool; DDX_Check cannot be used with bool at all.
• MFC arbitrarily switches off warnings in user code by default unless _AFX_ALL_WARNINGS and _ATL_ALL_WARNINGS are defined.

Hi,

We are absolutely committed to making sure that MFC is good neighbor with PSDK and VC compiler and even with WinForms. However in any change to its implementation we have to consider impact on existing code base. One of the biggest negative feedback we receive when releasing a new version of VC libraries is always about how a new version of libraries breaks existing source code builds. We carefully pick what we can and why we should be changing in MFC to avoid developers dealing with compiler errors and runtime breaks while porting existing code from one version of MFC to another. If we see that benefit of making this change does not justify introduction of yet another breaking change, we won't be making this change. However you are asking specific issues, so I will try addressing these first.

- #define NOMINMAX

This is not issue in VS2005 as far as I know. It has been fixed in Beta 1. If you still see, that please report it on connect.microsoft.com/visualstudio/

- The MFC object macros create member names from the class names, frustrating use of namespaces.

MFC was designed pre-namespaces. However, should be ok in most cases if you simply don’t pass in the namespace but put code inside part of the code that uses this namespace. No, we do not have plans addressing this in Orcas.

- Various MFC functions return BOOL, giving a compiler warning when converted to bool; DDX_Check cannot be used with bool at all.

Again MFC was designed pre-bool times. Thing with DDX_ routines is that they are very small and very basic code that anyone can copy from MFC sources and modify to meet some specific needs. For VC changing this API is a breaking change that may break existing code. And when breaking change does not bring a lot of value, we avoid doing it. Again, no plans changing this in Orcas.

- MFC arbitrarily switches off warnings in user code by default unless _AFX_ALL_WARNINGS and _ATL_ALL_WARNINGS are defined.

It is definitely not arbitrary. We carefully review which warnings we disable based on cases where the compiler warning is noisy given standard MFC/ATL patterns. These disables are renewed often, and relate to compiler changes we are often pushing for. There is sadly no simple solution to this, since MFC has constructs that we do provide useful compiler warnings for but which are safe in MFC and for which __pragma doesn’t work yet. Changing MFC in this area is a lot of work and time, which can be spend on other things, like adding support for new Vista controls. Sorry, again, no plans addressing this in Orcas. Actually I doubt we would ever change this in the future.

Hope this gives you some answers to your concerns. If you have more specific questions, please ask.

Thanks,
Nikola Dudar
VC++; //PM