Висячие Ссылки, ведущие к непредсказуемому поведению

я задал предыдущий вопрос о ссылках и непредсказуемое поведение здесь: previous question и на основе ответа, данного и некоторые замечания, такие как замечание user2079303, где они заявили это:Висячие Ссылки, ведущие к непредсказуемому поведению

ссылка обертка отлично работает, если у вас есть один «мастер» контейнер, содержащий сами (не ссылки) объекты, которые не изменяются, и другие контейнеры имеют ссылки на мастер

Мой новый вопрос становится это: будет эта помощь облегчает возможность оборванных ссылок что может привести к неопределенному поведению?

template<class T> 
class Wrapper { 
private: 
    T object; 
public: 
    T& referenced_object; 
    explicit Wrapper(T& obj) : object(obj), referenced_object(object) {} 
};

Это будет использоваться таким же образом, как показано в предыдущем вопросе, где несколько контейнеров будут занимать одни и те же ссылки объектов, где, если один объект изменяется в одном контейнере, то соответствующая ссылка этого объекта также будет изменена в другом контейнере.

источник

2017-01-05 Francis Cugler

Не побеждает ли цель оболочки, включая копию? Если вы посмотрите на 'std :: reference_wrapper', он запрещает создание из временных объектов, что означает, что он должен быть создан из того, что уже существует. До тех пор, пока вы понимаете время жизни ссылочного объекта, это действительная вещь. –

@PaulRooney Хмм Я дал обертку в предыдущем вопросе как ответ на другой вопрос, а другие говорили, что это плохой дизайн, что приведет к оборванным ссылкам и, следовательно, к неопределенному поведению. Поэтому я тогда задал предыдущий вопрос, и с ответом от пользователя2079303 это привело меня к этому. Я думал о том, что у меня есть действительный объект как закрытый, но только имея возможность иметь ссылку, доступную для него, тогда ваш комментарий действительно имеет смысл в том, что он побеждает цель. Я знаю о 'std :: reference_wrapper', но пытаюсь сделать очень простой. –

Все зависит от того, как вы разрабатываете свой код. Если вещь, которая берет ссылку или не владеющий указателем на что-то, что-то переживает, то у вас есть проблема. Если вы передаете их функции, но это нормально, так как переменная должна быть живой, пока функция запускается (не учитывая потоки). Вам действительно нужно сесть и посмотреть на дизайн и убедиться, что у вас нет случаев, когда объект, на который ссылается, не переживает ссылку. – NathanOliver

Такая обертка не имеет смысла, если вы храните ее сами, тогда нет необходимости в ссылках. И ваша ссылка становится недействительной, когда вы перемещаете этот объект (например, когда он хранится в std::vector и он перераспределяет память).

Ссылки и std::reference_wrapper Работает отлично, но не перемещайте свой объект. Сохранение объектов в std::list гарантирует, что они не будут перемещены, поэтому вы можете использовать его и указывать ссылки в нескольких контейнерах на свои объекты.

источник

2017-01-05 12:48:27

Хорошо, спасибо; просто хотел прояснить это, я изначально думал об этом, но потом начал второй догадываться. –

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

Было бы ... но каждый экземпляр этой оболочки будет держать свой собственный объект, и поэтому, следовательно, не будет достичь своей первоначальной цели «несколько контейнеров будет проводить одни и те же объекты, на которые ссылается»

также , неявный copy/move constructor/assign будет копировать/перемещать внутренний объект, но копия ссылки будет ссылаться на исходный объект вместо копии - что снова приводит к возможности оборванных ссылок.

Ссылка на эту обертку, как представляется, не имеет никакой цели.

источник

2017-01-05 13:01:52 user2079303

Висячие Ссылки, ведущие к непредсказуемому поведению

ответ

Смежные вопросы