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:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 )
{
// ...
}
Last edit: antred 2016-07-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Example 2 : Member variable 'CMembers::m_bCommBusy' is not initialized in the constructor.
Last edit: Sander Bouwhuis 2016-07-06
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:
Last edit: antred 2016-07-06
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.
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):
Last edit: antred 2016-07-07
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:
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.
Last edit: Sander Bouwhuis 2016-07-08
No. Cppcheck seems to not see the definition of CHECK_MEM_LEAKS. Did you provide correct include paths?
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.
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.