CWinApp relies on the CRT to initialize its members and may therefore access uninitialized data if it is created dynamically.At this point, we may start a discussion about whether or not it is feasible or allowed at all to instantiate the CWinApp instance statically or dynamically. The point is that it was possible to do so using VC.90 and it will be possible again if the proposed remedy mentioned below is applied.The crash is caused by the fact that CWinApp does not initialize all members. It relies on the CRT to fill all members with 0. Since CWinApp is a class - not a value type - I consider this bad design. Fix:1) Explicitly initialize members in the constructor: m_nCmdShow = 0; m_pszAppID = NULL; m_dwPromptContext = 0; m_dwPolicies = _AFX_SYSPOLICY_NOTINITIALIZED; 2) Add m_pszAppID to CWinApp::Dump() or mark that function "DEPRECATED" if it is obsolete.Please keep the following in mind when applying changes to MFC1) Do not rely on the runtime to initialize static data. Classes should always initialize all members unless that may impose a performance penalty.2) Do not crash the application if the user does not call a public member that is not mandatory (SetAppID)Please run the VS 2010 C++ Code Analysis at least once on your MFC sources and fix at least the very worst problems before publishing the next major MFC release.
Visual Studio/Silverlight/Tooling version
What category (if any) best represents this feedback?
Steps to reproduce
Operating System Language