C++ -Weff предупреждение с ++ с указателями

Это предупреждение, а не ошибка. У вас есть указатели, которые вы не склонны правильно использовать, имея конструктор по умолчанию. Определите конструкторы и операторы присваивания, если вы хотите, чтобы предупреждения исчезли. Правило трех / пяти / нуля

struct B {
    int* first;
    std::vector<int> second;

    B() : first(nullptr), second{} {}  // default
    B(const B&) = delete;              // copy ctor
    B(B&&) = delete;                   // move ctor
    B& operator=(const B&) = delete;   // copy assignment
    B& operator=(B&&) = delete;        // move assignment  
    ~B() { delete[] first; }           // dtor
};

Если вы этого не сделаете, перемещение и копирование экземпляров вашего класса может вызвать нежелательные эффекты со стороны созданных по умолчанию экземпляров конструкторов / операторов присваивания, таких как копирование / перемещение ресурсов, которые не могут быть скопированы / перемещены. Взгляните на деструктор и подумайте, что произойдет, если вы позволите методам по умолчанию работать с указателем.

С B компилятор может обнаружить, что Правило трех потенциально нарушается, и выдает эффективное предупреждение C. Решение этой проблемы хорошо освещено во многих других местах, начиная с ответа Теда Люнгмо на этот вопрос.

Но почему два других не вызывают такое же предупреждение?

C позволяет нам устранить половину проблемы: ссылочная переменная-член не может быть повторно назначена, чтобы компилятор не сгенерировал оператор присваивания по умолчанию, чтобы вызвать какое-либо горе.

C c; // uninitialized second. GCC misses this
C d;
c = d; //fails. deleted assignment operator

но конструктор копирования должен быть возможен и представлять потенциальную угрозу.

C c; // uninitialized second. GCC misses this
C d(c); // but it does catch the uninitialized second if you do this

Делаем модификацию C

std::vector<int> dummy;
struct C
{
    C() :second(dummy) // initialize second
    {

    }
    int * first = nullptr;
    std::vector<int>& second;
};

Позволяет

C c; 
C d(c); 

компилировать без предупреждения Effective C++, как A. Я долго не мог осмыслить это. Это поднимает важный момент. Предупреждения даны по милости разработчика. Если что-то доказать сложно или невозможно, предупреждения не будет.

Но почему это предупреждение сложно?

Компилятор должен знать, чтобы найти потенциальную проблему. Это означает, что он будет искать сигнатуру проблемы. Это означает, что один или несколько членов могут потребовать специальной обработки, деструктора, конструктора копирования или оператора присваивания без по крайней мере одной из двух других специальных функций-членов, требуемых Правилом трех.

Я подозреваю, что GCC запускает предупреждение Effective C++, когда находит хотя бы одну из специальных функций-членов, но не все.

Давайте посмотрим на деструкторы трех классов. Aint не требует специальной логики уничтожения. Также нет ссылки на C. Bvector - совсем другая история. По крайней мере, ему нужно освободить место для хранения. Это требует, чтобы компилятор сгенерировал некоторый код, и как только есть деструктор, который не выполняет никаких действий, компилятор может увидеть, что у класса есть деструктор без двух других частей правила трех и содержит члены, которые могут потребовать специальной обработки ( указатель).

Так

struct C
{
    C() :second(dummy)
    {

    }
    ~C() // force a destructor
    {

    }
    int * first = nullptr;
    std::vector<int>& second;
};

Должно появиться и вызывает эффективное предупреждение C++.

Примечание: совершенно тривиальный конструктор копирования, созданный

C c; 
C d(c); 

само по себе не вызывает предупреждения. Также нет конструктора копирования. Ловушка предупреждения может находиться исключительно в деструкторе, что приводит к предупреждению о предупреждениях, существующих только по милости разработчика.