Self assignment in initialisation

-Weffc++ is definitely not the answer! The warning just says, that the initialization should go to initialization list. If You do that, the warning disappears:

#include <iostream> class B { public: B() : m(17) { std::cout << "B()" << std::endl; } B(const B & o) : m(o.m) { std::cout << "B(const B& o)" << std::endl; } B & operator=(const B & o) { std::cout << "B & operator=(const B & o)" << std::endl; m = o.m; return *this; } int m; }; int main() { B b = b; int i = i; std::cout << b.m << " " << i << std::endl; } 

The compiler at the live example gives a warning for the simple variable i, but not for the class variable b. So the question remains unanswered - Why does the compiler warn for a simple type, but not for a more complex one?

As @Nawaz has stated and @kcm1700 warnings are not a requirement for the compiler.

As to why this flag -weffc++ seems to be more strict than -Wall -Wextra -pedantic see the online docs: http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html.

You can see from the docs:

The following -W... options are not affected by -Wall.

-Weffc++ (C++ and Objective-C++ only) Warn about violations of the following style guidelines from Scott Meyers' Effective C++ series of books: Define a copy constructor and an assignment operator for classes with dynamically-allocated memory. Prefer initialization to assignment in constructors. Have operator= return a reference to *this. Don't try to return a reference when you must return an object. Distinguish between prefix and postfix forms of increment and decrement operators. Never overload &&, ||, or ,. This option also enables -Wnon-virtual-dtor, which is also one of the effective C++ recommendations. However, the check is extended to warn about the lack of virtual destructor in accessible non-polymorphic bases classes too.

When selecting this option, be aware that the standard library headers do not obey all of these guidelines; use ‘grep -v’ to filter out those warnings.

So if you add the -weffc++ flag then it will generate the desired warning:

g++-4.8 -std=c++11 -Weffc++ -Wall -Wextra -pedantic main.cpp && ./a.out main.cpp: In constructor 'B::B()': main.cpp:6:5: warning: 'B::m' should be initialized in the member initialization list [-Weffc++] B() ^ main.cpp: In copy constructor 'B::B(const B&)': main.cpp:12:5: warning: 'B::m' should be initialized in the member initialization list [-Weffc++] B(const B & o) ^ 

See live example and related:Easy way find uninitialized member variables

For your modified examples in the comments, clang detects both correctly, see this: http://coliru.stacked-crooked.com/a/d1a55f347ee928be and http://coliru.stacked-crooked.com/a/9676797c7d155b81

The output is:

main.cpp:27:12: warning: variable 'b' is uninitialized when used within its own initialization [-Wuninitialized] B b = b; ~ ^ 1 warning generated. 

Different compilers will have different competencies with respect to detecting such problems.