False positive uninitMemberVar

[Sander Bouwhuis]

I updated to v1.74 and now I get a lot of "Member variable 'xxx::xxx is not initialized in the constructor."

Example 1 : Member variable 'CEvents::m_eMode' is not initialized in the constructor.

// The constructor
CEvents::CEvents()
{
  ENTER_FUNCTION_DEBUG_LOG_TO_MEM

  try
  {
    CHECK_MEM_LEAKS

    // Initialize the object's variables
    m_eMode      = MODE::mode_view;
    m_pDcgBase   = nullptr;
    m_pDcgExtra  = nullptr;
    m_pLstEvents = nullptr;
    m_pTabInfo   = nullptr;
    m_pUser      = nullptr;
  }
  catch(...) { OnException(__FILE__, __LINE__, __FUNCSIG__, __TIMESTAMP__); }
}

Example 2 : Member variable 'CMembers::m_bCommBusy' is not initialized in the constructor.

// The constructor
CMembers::CMembers()
{
  ENTER_FUNCTION_DEBUG_LOG_TO_MEM

  try
  {
    CHECK_MEM_LEAKS

    // Initialize the variables
    m_bCommBusy          = false;
    m_bDocumentZoomed    = false;
    m_bPhotoZoomed       = false;
    m_bTcpIpMode         = false;
    m_bThumbnails        = false;
    m_eDocumentType      = DOCUMENT_TYPE::document_type_none;
    m_eMemberMode        = MEMBER_SHOW::show_none;
    m_hComboDocuments    = NULL;
    m_hEditDocument      = NULL;
    m_hEditMemo          = NULL;
    m_i32Function        = -1;
    m_i32PersonId        = 0;
    m_pComm              = nullptr;
    m_pEventsMembers     = new COMMUNICATION_EVENTS[MAX_COMMUNICATION_EVENTS]();
    m_pEventsProspects   = new COMMUNICATION_EVENTS[MAX_COMMUNICATION_EVENTS]();
    m_pLstMemberData     = nullptr;
    m_pLstMembers        = nullptr;
    m_pLstMiscData       = nullptr;
    m_pTabInfo           = nullptr;
    m_u16MemberDataQuery = 0;
    m_u16MiscQuery       = 0;
    memset(m_ppwcTemplates,         NULL, sizeof(m_ppwcTemplates));
    memset(m_pwcCustPayMethod_1,    NULL, sizeof(m_pwcCustPayMethod_1));
    memset(m_pwcCustPayMethod_2,    NULL, sizeof(m_pwcCustPayMethod_2));
    memset(m_pwcExtQueriesDir,      NULL, sizeof(m_pwcExtQueriesDir));
    memset(m_pwcExtQueryMemberData, NULL, sizeof(m_pwcExtQueryMemberData));
    memset(m_pwcExtQueryMisc,       NULL, sizeof(m_pwcExtQueryMisc));
  }
  catch(...) { OnException(__FILE__, __LINE__, __FUNCSIG__, __TIMESTAMP__); }
}

[antred]

Technically, the warning is correct. You're not initializing, you're assigning (and yes, there's a difference ... Google is your friend, if you're unsure). To initialize, use initialization lists. Example:

CEvents::CEvents() : m_eMode( MODE::mode_view ), m_pDcgBase( nullptr ), m_pDcgExtra( m_pDcgExtra ) // ...
{
  //...
}

[Sander Bouwhuis]

That's the error?!?

Initialization can't do exception handling so is not always an option. Also, sometimes there are conditional situations that require if/else to initialize member variables.

[antred]

It's not an error; it's a warning (right?). Also for conditional initialization, you could always use the ternary operator. And if initialization of the member could throw then just assign the member in the constructor body like you're already doing and live with the warning ... OR move initialization out to a separate function (may or may not be worth it ... it depends):

auto initMyVar( int arg, int anotherArg ) -> int
{
    if ( arg > 3 )
    {
        return 0;
     }

     try
     {
         // ...
         return 42;
     }
     catch ( /* what ever you want to catch */ )
     {
         return -1;
     }
}

CEvents::CEvents( int arg, int anotherArg ) : m_myIntMemmber( initMyVar( arg, anotherArg ) ), m_anotherMember( arg < 1 ? 56.6 : 100.0 )
{
    // ...
}

[Mr. X]

That's the error?!?

No, of course not.

What happens if you remove CHECK_MEM_LEAKS (for example by -DCHECK_MEM_LEAKS=, which makes the preprocessor removing the macro)?

[Sander Bouwhuis]

No, of course not.

What happens if you remove CHECK_MEM_LEAKS (for example by -DCHECK_MEM_LEAKS=, which makes the preprocessor removing the macro)?

CHECK_MEM_LEAKS is doing nothing. This is how I defined it:

// Enable this define to check for all memory leaks
#define CHECK_MEM_LEAKS
//#define CHECK_MEM_LEAKS   { if(!_CrtCheckMemory()) DebugBreak(); }

I just tested commenting out the CHECK_MEM_LEAKS line in the CMembers.cpp file and then it works properly.
So, it's definitely a bug in CppCheck.

[Mr. X]

So, it's definitely a bug in CppCheck.

No. Cppcheck seems to not see the definition of CHECK_MEM_LEAKS. Did you provide correct include paths?

[Sander Bouwhuis]

There are no include paths. Everything is under the rootpath I provide CppCheck with. In the root I have the .sln file, and in sub-directories I have a dozen projects belonging to the solution.

Here is the directory structure:
C:\Projects\Dms v4.0.2\AccessControl
C:\Projects\Dms v4.0.2\AccessControl\Resources
C:\Projects\Dms v4.0.2\Bookings
C:\Projects\Dms v4.0.2\Bookings\Resources
C:\Projects\Dms v4.0.2\Classes
C:\Projects\Dms v4.0.2\Classes\Libs_32
C:\Projects\Dms v4.0.2\Classes\Libs_32\Dll
C:\Projects\Dms v4.0.2\Classes\Libs_32\Dll\Plugin
C:\Projects\Dms v4.0.2\Classes\Libs_32\Dll\SPM
C:\Projects\Dms v4.0.2\Classes\Libs_64
C:\Projects\Dms v4.0.2\Classes\Libs_64\Dll
C:\Projects\Dms v4.0.2\Classes\Libs_64\Dll\Plugin
C:\Projects\Dms v4.0.2\Classes\Libs_64\Dll\SPM
C:\Projects\Dms v4.0.2\Classes\Resources
C:\Projects\Dms v4.0.2\Common
C:\Projects\Dms v4.0.2\Common\Resources
C:\Projects\Dms v4.0.2\Crm
C:\Projects\Dms v4.0.2\Dashboard
C:\Projects\Dms v4.0.2\Dms
C:\Projects\Dms v4.0.2\Dms\Resources
C:\Projects\Dms v4.0.2\Finance
C:\Projects\Dms v4.0.2\ipch
C:\Projects\Dms v4.0.2\ipch\members-333b8e93
C:\Projects\Dms v4.0.2\ipch\reporting-53ac67b1
C:\Projects\Dms v4.0.2\Launcher
C:\Projects\Dms v4.0.2\Launcher\Libs_32
C:\Projects\Dms v4.0.2\Launcher\Libs_64
C:\Projects\Dms v4.0.2\Launcher\Resources
C:\Projects\Dms v4.0.2\Members
C:\Projects\Dms v4.0.2\Purse
C:\Projects\Dms v4.0.2\Reporting
C:\Projects\Dms v4.0.2\Reporting\Resources
C:\Projects\Dms v4.0.2\System
C:\Projects\Dms v4.0.2\Training
C:\Projects\Dms v4.0.2\Training\Resources

CHECK_MEM_LEAKS is defined in a header file in the Classes library, which is included by all the other projects.

[Daniel Marjamäki]

cppcheck does not search for included headers recursively. I like the idea to do that. however sometimes it would mean the wrong header is included.

so you have to explicitly tell cppcheck where to search for headers with -I.

you can use the "--check-config" flag to see missing headers etc. That will print warnings about standard headers but I do recommend that you ignore those warnings. only include your own headers and possibly 3rd party library headers.