Вызов нестатической функции-члена вне времени жизни объекта в С++ 17

Ответ 1

Это правда, что тривиальные деструкторы вообще ничего не делают, даже не заканчивают время жизни объекта до (в планах) С++ 20. Таким образом, вопрос тривиален, если только мы не предполагаем нетривиальный деструктор или что-то более сильное, например, delete.

В этом случае упорядочение в С++ 17 не помогает: вызов (не доступ к члену класса) использует указатель на объект (для инициализации this) в нарушение правил для устаревшие указатели.

Примечание: если бы только один порядок был неопределенным, то был бы "неопределенный порядок" до С++ 17: если любая из возможностей для неопределенного поведения - это неопределенное поведение, поведение не определено. (Как бы вы сказали, что был выбран четко определенный вариант? Неопределенный мог бы подражать ему, а затем выпустить носовых демонов.)

Ответ 2

Постфиксное выражение a->f секвенируется перед вычислением любых аргументов (которые неопределенно секвенированы относительно друг друга). (См. [Expr.call])

Оценка аргументов упорядочена перед телом функции (даже встроенные функции, см. [Intro.execution])

Смысл в том, что вызов самой функции не является неопределенным поведением. Тем не менее, доступ к любым переменным-членам или вызов других функций-членов в пределах будет UB на [basic.life].

Таким образом, вывод заключается в том, что этот конкретный случай является безопасным в соответствии с формулировкой, но опасный метод в целом.

Ответ 3

Похоже, вы предполагаете, что a->f(0) имеет следующие шаги (в таком порядке для самого последнего стандарта C++, в некотором логическом порядке для предыдущих версий):

• оценивая *a
• вычисление a->f (так называемая связанная функция-член)
• оценка 0
• вызов связанной функции-члена a->f в списке аргументов (0)

Но у a->f нет ни значения, ни типа. По сути, это не вещь, бессмысленный синтаксический элемент, необходимый только потому, что грамматика разлагает доступ к элементу и вызов функции, даже при вызове функции-члена, который по определению объединяет доступ к элементу и вызов функции.

Поэтому вопрос о том, когда "TG47" "оценивается", является бессмысленным вопросом: не существует такого понятия, как отдельный шаг оценки для выражения a->f без значения и без типа.

Поэтому любые рассуждения, основанные на таких обсуждениях порядка оценки не-сущности, также являются недействительными и недействительными.

EDIT:

На самом деле это хуже, чем то, что я написал, выражение a->f имеет фальшивый "тип":

E1.E2 - это 'функция списка параметров типа cv, возвращающая T'.

Функция function-type-list cv - это даже не то, что было бы допустимым декларатором вне класса: нельзя иметь f() const в качестве декларатора, как в глобальном объявлении:

int ::f() const; // meaningless

И внутри класса f() const это не означает "функцию параметра-типа-списка =() с cv = const", это означает функцию-член (параметра-типа-списка =() с cv = const). Не существует надлежащего декларатора для правильной "функции списка параметров типа cv". Он может существовать только внутри класса; нет функции типа "список параметров типа cv, возвращающего T", который может быть объявлено или что могут иметь реальные вычислимые выражения.

Ответ 4

В дополнение к тому, что говорили другие:

a-> ~ А(); удалить;

Эта программа имеет утечку памяти, которая технически не является неопределенным поведением. Однако, если вы вызвали delete a;, чтобы предотвратить это - это должно было быть неопределенное поведение, потому что delete будет вызывать a->~A() во второй раз [Раздел 12.4/14].

a-> ~ А()

Иначе в действительности это так, как другие предлагали - компилятор генерирует машинный код в соответствии с A* a = malloc(sizeof(A)); a->A(); a->~A(); a->f(0);. Поскольку нет переменных-членов или виртуальных элементов, все три функции-члена пусты ({return;}) и ничего не делают. Указатель a даже указывает на правильную память. Он будет работать, но отладчик может жаловаться на утечку памяти.

Однако использование любых нестатических переменных-членов внутри f() могло бы быть неопределенным поведением, потому что вы обращаетесь к ним после того, как они (неявно) уничтожены сгенерированным компилятором ~A(). Это может привести к ошибке во время выполнения, если это будет что-то вроде std::string или std::vector.

удалить

Если вы замените a->~A() выражением, которое вместо этого вызвало delete a;, то я считаю, что это было бы неопределенным поведением, поскольку указатель a больше не действителен в этой точке.

Несмотря на это, код должен работать без ошибок, потому что функция f() пуста. Если он обращался к каким-либо переменным-членам, это могло привести к сбою или к случайным результатам, поскольку память для a освобождена.

новый (а) А

auto a = new A; new(a) A; само по себе является неопределенным поведением, потому что вы вызываете A() второй раз для той же памяти.

В этом случае вызов f() сам по себе был бы действительным, потому что a существует, но создание a дважды - это UB.

Он будет работать нормально, если A не содержит объектов с конструкторами, выделяющими память и тому подобное. В противном случае это может привести к утечкам памяти и т.д., Но f() получит доступ ко "второй" копии.

Ответ 5

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

#include <iostream>
#include <exception>

struct A {
    int x{5};
    void f(int){}
    int g() { std::cout << x << '\n'; return x; }
};

int main() {
    try {
        auto a = new A;
        a->f((a->~A(), a->g()));
    catch(const std::exception& e) {
        std::cerr << e.what();
        return EXIT_FAILURE;
    }
    return EXIT_SUCCESS;
}

Я использую Visual Studio 2017 CE с флагом языка компилятора, установленным на /std:c++latest, и моя версия IDE - 15.9.16, и я получаю следующий вывод на консоль и выход из программы:

консольный вывод

5

Вывод статуса выхода из IDE

The program '[4128] Test.exe' has exited with code 0 (0x0).

Так что, похоже, это определено в случае Visual Studio, я не уверен, как другие компиляторы будут относиться к этому. Деструктор вызывается, однако переменная a все еще находится в динамической памяти кучи.

Давайте попробуем еще одну небольшую модификацию:

#include <iostream>
#include <exception>

struct A {
    int x{5};
    void f(int){}
    int g(int y) { x+=y; std::cout << x << '\n'; return x; }
};

int main() {
    try {
        auto a = new A;
        a->f((a->~A(), a->g(3)));
    catch(const std::exception& e) {
        std::cerr << e.what();
        return EXIT_FAILURE;
    }
    return EXIT_SUCCESS;
}

консольный вывод

8

Вывод состояния выхода из среды IDE

The program '[4128] Test.exe' has exited with code 0 (0x0).

На этот раз не давайте больше менять класс, а потом позвольте позвонить члену...

int main() {
    try {
        auto a = new A;
        a->f((a->~A(), a->g(3)));
        a->g(2);
    } catch( const std::exception& e ) {
        std::cerr << e.what();
        return EXIT_FAILURE;
    }
    return EXIT_SUCCESS;
}

консольный вывод

8
10

Вывод статуса выхода из IDE

The program '[4128] Test.exe' has exited with code 0 (0x0).

Здесь кажется, что a.x сохраняет свое значение после вызова a->~A(), так как new был вызван на A, а delete еще не был вызван.

Еще больше, если я удалю new и использую указатель стека вместо выделенной динамической памяти кучи:

int main() {
    try {
        A b;
        A* a = &b;    
        a->f((a->~A(), a->g(3)));
        a->g(2);
    } catch( const std::exception& e ) {
        std::cerr << e.what();
        return EXIT_FAILURE;
    }
    return EXIT_SUCCESS;
}

Я все еще получаю:

консольный вывод

8
10

Вывод состояния выхода из среды IDE

  Когда я изменяю настройку флага языка компилятора с /c:std:c++latest на /std:c++17, я получаю точно такие же результаты.

То, что я вижу в Visual Studio, кажется, что оно четко определено без создания UB в контексте того, что я показал. Однако с точки зрения языка, когда речь идет о стандарте, я бы не стал полагаться и на этот тип кода. Вышеприведенное также не учитывает, когда класс имеет внутренние указатели, как автоматическое хранение в стеке, так и динамическое выделение кучи, и если конструктор вызывает new для этих внутренних объектов, а деструктор вызывает delete для них.

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