Возможно ли иметь ошибку сегментации от ссылки?

Question

Пусть следующий код:

Foo & foo = getFoo(); 
foo.attr; // 100% safe access? 

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

Я пробовал некоторые примеры, например, пытаться сделать NULL объекту Foo, но я получил ошибки компиляции. Я просто хочу быть уверенным, что вышеуказанный код всегда безопасен и что нет никакой внутренней внутренней черной магии C++, о которой я должен знать.

Из ответа Бенджамина я мог бы привести пример кода, где я получаю segmentation fault из справки, поэтому он отвечает на мой вопрос. Я вставлю свой код на случай, если кто-то заинтересован в будущем:

#include <iostream> 
using namespace std; 

class B 
{ 
    public: 
    int x; 
    B() {x = 5;} 
}; 
class A 
{ 
    public: 
    void f() 
    { 
     b = *(B*)NULL; 
    } 
    B & getB() 
    { 
     return b; 
    } 

    B b; 
}; 

int main() 
{ 
    A a; 
    a.f(); 

    cout << a.getB().x << endl; 
    return 0; 
} 

Answer 1

Да, это возможно.

Foo& Fr = *(Foo*)nullptr; 

Технически это уже неопределенное поведение для разыменования этого указателя. Но это скорее всего не приведет к какой-либо заметной ошибке. Это, вероятно, будет хотя:

Fr.attr = 10; 

Однако, как Джонатан Wakely указывает в комментариях, нет никаких оснований для Вас, чтобы проверить для случая, как это. Если функция возвращает недопустимую ссылку, эта функция прерывается и ее необходимо устранить. Ваш код использования не нарушен, если предположить, что ссылка действительна. Однако действительная ссылка может стать недействительной (хотя и не пустой) в совершенно законном коде, как указано в ответе Дэвида Шварца. Но вы не можете проверить это. Вам просто нужно знать, в каких случаях это может произойти, а затем прекратить использовать ссылку.

Answer 2

Возможно, имеется ссылка на плохую память. И поэтому ответ foo.attr; // 100% safe access?, нет. Рассмотрим следующий пример:

int &something() { 
    int i = 5, &j = i; 
    return j; // Return reference to local variable. This is destroyed at end of scope. 
} 

int main() { 
    int &k = something(); // Equivalent to getFoo() 
    std::cout << k << endl; // Using this reference is undefined behavior. 
    return 0; 
} 

Live example.

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

Answer 3

Ссылка должна ссылаться на действительный объект, когда эта ссылка установлена. Это стандартное требование C++, и любой код, который его нарушает, является UB и может делать буквально все.

Однако совершенно законно уничтожать объект, на который ссылается ссылка после того, как эта ссылка установлена. В этот момент доступ к ссылке является незаконным. Например:

std::vector<int> j; 
j.push_back(3); 
int& k = j.front(); // legal, object exists now 
j.clear();   // legal, object may be destroyed while reference exists 
k++;    // illegal, destruction of object invalidates reference 

Это означает, что функция, возвращающая ссылку, всегда должна возвращать ссылку, которая действительна при ее возврате. Вот почему вызов front на пустой вектор - UB - ссылка должна быть действительной, когда она сидит.Однако часто бывают ситуации, которые впоследствии могут привести к недействительности этой ссылки, и вам нужно понять, что это за условия, если вы планируете попытаться скрыть ссылку и получить доступ к ней позже.

Как правило, вы должны предположить, что это небезопасно, чтобы спрятать возвращаемую ссылку и получить к ней доступ позже, если вы не знаете, что ссылка останется действительной. Например, std::vector тщательно объясняет, при каких условиях ссылка в контейнер может быть недействительной и включает последующий вызов push_back. Так что это битый:

std::vector<int> j; 
j.push_back(3); 
int &first = j.front(); 
j.push_back(4); 
int &second = j.back(); 
if (first == second) // illegal, references into container are invalidated by push_back 

Но это нормально:

std::vector<int> j; 
j.push_back(3); 
j.push_back(4); 
int &first = j.front(); 
int &second = j.back(); 
if (first == second) // legal, references into container stay valid