Ссылка на заостренный объект

Question

Указатели разыменования могут сделать код очень трудным для чтения. Обычно я делаю ссылку на заостренный объект и работу со ссылкой. Пример:

shared_ptr<std::vector<int> > sp = get_sp_to_vector(); 
std::vector<int>& vec = *sp; 
... 
vec.push_back(5); 

Удивительно, если это хорошая практика. Есть ли у него недостаток?

Update: Чтобы завершить пример, я определил бы get_sp_to_vector() следующим образом:

shared_ptr<std::vector<int> > get_sp_to_vector() 
{ 
    // create a vector and send back a shared pointer pointing at it 
    shared_ptr<std::vector<int> > sp(new std::vector<int>); 
    sp->push_back(1); sp->push_back(3); 
    return sp; 
} 

Answer 1

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

Это, как правило, не трудно гарантировать, но вот некоторые плохие примеры:

shared_ptr<X> p = get_p(); 
X& r = *p; 
p.reset(); // might result in destroying r 
use(r); // oops 

// or: 
shared_ptr<X> p = get_p(); 
X& r = *p; 
p = get_some_other_p(); // might result in destroying r 
use(r); // oops 

Answer 2

Я не считаю, что это хорошая практика. Указатели являются основным местом разработки C/C++ и b/c этого, кодеки C/C++ удобны с синтаксисом de-reference, необходимым для указателей. Я стараюсь избегать использования указателей, когда это возможно (не для синтаксических соображений), но иногда это просто лучший инструмент для работы. Если у вас есть код, который является gnarly b/c, вы используете указатель, я бы, как правило, де-ссылку на него в функцию, которая передает объект по ссылке, которая по существу делает то, что вы делаете, но, на мой взгляд, она делает это в более элегантный способ. Таким образом, вместо:

shared_ptr<std::vector<int> > sp = get_sp_to_vector(); 
std::vector<int>& vec = *sp; 
...ugly stuff... 
vec.push_back(5); 

Я хотел бы сделать:

void func(std::vector<int> &vec) 
{ 
    ... previously ugly stuff... 
    vec.push_back(5); 
} 

shared_ptr<std::vector<int> > sp = get_sp_to_vector(); 
func(*sp); 

EDIT:
Это не означает, что вы должны создать функцию, чтобы просто создать более хороший синтаксис для указателей, так как она является укажите, что если вам не нравится синтаксис указателя, и ваш код использует чистые и сжатые функции, вы можете просто заставить функции брать ссылки и де-ссылаться на свой указатель при вызове функции. В ситуациях, когда у вас есть только несколько вызовов на * p или p-> x, кажется глупым создать функцию со ссылкой или создать ссылку, чтобы вызвать p.x. Просто используйте синтаксис указателя в этих случаях, так как это синтаксис C/C++.

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

Answer 3

ИМХО, я думаю, что это приемлемая практика (с некоторыми оговорками - см Roger Pate's пост). Если вы добавляете строку кода только для вызова push_back(), я не думаю, что это приемлемо.

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

Answer 4

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

Answer 5

Работа назад из предложенного вами кода, я не согласен, что:

shared_ptr<std::vector<int> > sp = get_sp_to_vector(); 
... 
sp->push_back(5); 

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

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