Ловля C++ повисшая ссылка

Я не думаю, что какой-либо статический инструмент может это обнаружить, но если вы используете Valgrind вместе с некоторыми модульными тестами или любым другим кодом, который падает (seg fault), вы можете легко найти, куда ссылается память и где она была выделена изначально.

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

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

Чтобы прояснить, что я имею в виду под "указателями под капотом", возьмем два следующих класса. Один использует ссылки, другой - указатели.

class Ref
{
  int &ref;
public:
  Ref(int &r) : ref(r) {};
  int get() { return ref; };
};

class Ptr
{
  int *ptr;
public:
  Ptr(int *p) : ptr(p) {};
  int get() { return *ptr; };
};

Теперь сравните сгенерированный код для этих двух классов.

@@Ref@$bctr$qri proc    near  // Ref::Ref(int &ref)
    push      ebp
    mov       ebp,esp
    mov       eax,dword ptr [ebp+8]
    mov       edx,dword ptr [ebp+12]
    mov       dword ptr [eax],edx
    pop       ebp
    ret 

@@Ptr@$bctr$qpi proc    near  // Ptr::Ptr(int *ptr)
    push      ebp
    mov       ebp,esp
    mov       eax,dword ptr [ebp+8]
    mov       edx,dword ptr [ebp+12]
    mov       dword ptr [eax],edx
    pop       ebp
    ret 

@@Ref@get$qv    proc    near // int Ref:get()
    push      ebp
    mov       ebp,esp
    mov       eax,dword ptr [ebp+8]
    mov       eax,dword ptr [eax]
    mov       eax,dword ptr [eax]
    pop       ebp
    ret 

@@Ptr@get$qv    proc    near // int Ptr::get()
    push      ebp
    mov       ebp,esp
    mov       eax,dword ptr [ebp+8]
    mov       eax,dword ptr [eax]
    mov       eax,dword ptr [eax]
    pop       ebp
    ret 

Видите разницу? Никакой.

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

Если вы имели в виду , вместо этого верните S (значение) , тогда, ради всего святого, КОПИРОВАТЬ, ВСТАВЬТЕ КОД, ПУБЛИКОВАННЫЙ ЗДЕСЬ .

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

Когда вы публикуете вопрос в Интернете, если этот вопрос включает код, НАПИСАТЬ ТОЧНЫЙ КОД .

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

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

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

Есть руководство, которому я следую после того, как меня побили именно этим:

Когда в классе есть член-ссылка (или указатель на что-то, что может иметь время жизни, которое вы не контролируете), сделайте объект некопируемым.

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

Это совершенно правильный код.

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

const S& s1 = function(); // valid

S& s2 = function(); // invalid

Это явно разрешено в стандарте C ++ .

См. 12.2.4:

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

и 12.2.5:

Второй контекст - это когда ссылка привязана к временному объекту. Временный объект, к которому привязана ссылка, или временный объект, являющийся полным объектом подобъекта, к которому привязана ссылка, сохраняется в течение всего времени существования ссылки, за исключением: [...]

Вы должны использовать технологию, основанную на инструментах времени компиляции. Хотя valgrind мог проверять все вызовы функций во время выполнения (malloc, free), он не мог проверять только код .

В зависимости от вашей архитектуры, IBM PurifyPlus найдет некоторые из этих проблем. Поэтому вам следует найти действующую лицензию (или использовать лицензию вашей компании) для ее использования или попробовать ее с пробной версией.