Я розумію синтаксис та загальну семантику покажчиків порівняно з посиланнями, але як я повинен вирішити, коли більш-менш доцільно використовувати посилання чи покажчики в API?

Звичайно, для деяких ситуацій потрібна та чи інша ( operator++потребує довідкового аргументу), але в цілому я вважаю, що я вважаю за краще використовувати покажчики (і const покажчики), оскільки синтаксис зрозумів, що змінні передаються деструктивно.

Наприклад у наступному коді:

void add_one(int& n) { n += 1; }
void add_one(int* const n) { *n += 1; }
int main() {
  int a = 0;
  add_one(a); // Not clear that a may be modified
  add_one(&a); // 'a' is clearly being passed destructively
}

З вказівником завжди (більше) очевидно, що відбувається, тому для API та подібних, де чіткість викликає велике занепокоєння, вказівники не є більш доцільними, ніж посилання? Чи означає це, що посилання повинні використовуватися лише тоді, коли це необхідно (наприклад operator++)? Чи є якісь проблеми щодо ефективності роботи з тим чи іншим?

РЕДАКТИРУВАННЯ (ЗАРАЗ):

Окрім дозволу NULL значень та роботи з необробленими масивами, схоже, вибір зводиться до особистих переваг. Я прийняв відповідь нижче, що посилається на керівництво по стилю C ++ Google , оскільки вони представляють думку про те, що "Посилання можуть бути заплутаними, оскільки вони мають синтаксис значення, але семантику вказівника".

У зв'язку з додатковою роботою, необхідною для очищення аргументів вказівника, які не повинні бути NULL (наприклад, add_one(0)буде викликати версію вказівника та перерву під час виконання), з точки зору ремонтопридатності має сенс використовувати посилання там, де ОБОВ'ЯЗКОВО повинен бути присутнім, хоча це соромно втратити синтаксичну ясність.

Використовуйте посилання, де можна, вказівники, куди потрібно.

Уникайте покажчиків, поки не зможете.

Причина полягає в тому, що вказівники ускладнюють дотримання / читання, менш безпечні та набагато небезпечніші маніпуляції, ніж будь-які інші конструкції.

Тож правилом є використання покажчиків, лише якщо іншого вибору немає.

Наприклад, повернення вказівника на об’єкт - допустимий варіант, коли функція може повернути nullptr в деяких випадках і передбачається, що це буде. Однак, кращим варіантом буде використання чогось подібного boost::optional.

Інший приклад - використання покажчиків на необмежену пам'ять для конкретних маніпуляцій з пам'яттю. Це має бути прихованим та локалізованим у дуже вузьких частинах коду, щоб допомогти обмежити небезпечні частини всієї кодової бази.

У вашому прикладі немає сенсу використовувати вказівник як аргумент, оскільки:

1. якщо ви подаєте nullptrв якості аргументу, ви збираєтесь у не визначеній поведінці;
2. версія посилального атрибута не дозволяє (без легких поміток хитрощів) проблему з 1.
3. версія атрибута посилання простіша для розуміння для користувача: ви повинні надати дійсний об’єкт, а не те, що може бути недійсним.

Якщо поведінка функції повинна працювати з певним об'єктом або без нього, то використання вказівника як атрибута говорить про те, що ви можете передавати nullptrяк аргумент, і це добре для функції. Це свого роду договір між користувачем та реалізацією.

Вистави точно такі ж, оскільки посилання реалізуються внутрішньо як покажчики. Таким чином, вам не потрібно про це турбуватися.

Не існує загальновизнаної конвенції щодо використання посилань та покажчиків. У кількох випадках вам потрібно повернути або прийняти посилання (наприклад, конструктор копій), але крім того, ви можете робити так, як хочете. Досить поширеною умовою, з якою я стикався, є використання посилань, коли параметр повинен посилатися на існуючий об'єкт, і вказівники, коли значення NULL нормально.

Деякі умови кодування (як-от Google ) передбачають, що завжди слід використовувати покажчики чи посилання const, оскільки посилання мають дещо незрозумілий синтаксис: вони мають референтну поведінку, але значення синтаксису.

Від C ++ FAQ Lite -

Користуйтеся посиланнями, коли можете, і вказівниками, коли потрібно.

Посилання, як правило, перевагу над покажчиками, коли вам не потрібно "повторно" повторно. Зазвичай це означає, що посилання є найбільш корисними в загальнодоступному інтерфейсі класу. Посилання зазвичай з'являються на шкірі предмета, а вказівники - на внутрішній стороні.

Виняток із зазначеного вище, коли параметр функції або значення, що повертається, потребує посилання "sentinel" - посилання, яке не посилається на об'єкт. Зазвичай це найкраще зробити, повернувши / взявши вказівник і надавши вказівнику NULL це особливе значення (посилання повинні завжди мати псевдоніми об'єктів, а не відреферентований покажчик NULL).

Примітка: Програмістам старого рядка C іноді не подобаються посилання, оскільки вони надають опорну семантику, яка не є явною в коді абонента. Однак після досвіду C ++ можна швидко зрозуміти, що це форма приховування інформації, яка є активом, а не зобов'язанням. Наприклад, програмісти повинні писати код мовою проблеми, а не мовою машини.

Моє правило:

• Використовуйте покажчики для вихідних або вхідних / вихідних параметрів. Тож видно, що значення буде змінено. (Ви повинні використовувати &)
• Використовуйте покажчики, якщо параметр NULL є прийнятним значенням. (Переконайтесь, що це constякщо вхідний параметр)
• Використовуйте посилання для вхідного параметра, якщо він не може бути NULL і не є примітивним типом ( const T&).
• Використовуйте вказівники або смарт-покажчики, повертаючи новостворений об’єкт.
• Використовуйте покажчики або смарт-покажчики як члени структури або класу замість посилань.
• Використовуйте посилання для отримання дозволу (наприклад, int &current = someArray[i])

Незалежно від того, який ви використовуєте, не забудьте задокументувати свої функції та значення їх параметрів, якщо вони не очевидні.

Відмова: окрім того, що посилання не можуть бути НУЛЬНИми та не відновлюватися (тобто те не може змінити об'єкт, яким вони є псевдонім), воно дійсно зводиться до питання смаку, тому я не збираюся говорити "це краще".

Однак, я не згоден з вашим останнім твердженням у публікації, оскільки я не думаю, що код втрачає ясність із посиланнями. У вашому прикладі

add_one(&a);

може бути зрозумілішим ніж

add_one(a);

оскільки ви знаєте, що, швидше за все, значення a зміниться. З іншого боку, хоча, підпис функції

void add_one(int* const n);

дещо не зрозуміло: чи буде n одиничним цілим чи масивом? Іноді у вас є лише доступ до (погано документованих) заголовків і подібних підписів

foo(int* const a, int b);

непросто інтерпретувати з першого погляду.

Імхо, посилання настільки ж хороші, як і покажчики, коли не потрібно (повторне) виділення чи повторне перев’язування (у сенсі, поясненому раніше). Більше того, якщо розробник використовує лише покажчики для масивів, підписи функцій дещо менш неоднозначні. Не кажучи вже про те, що синтаксис операторів набагато легше читається з посиланнями.

Як і інші вже відповіли: посилання завжди використовувати, якщо на змінному NULL/ nullptrне є дійсно дійсним станом.

Точка зору Джона Кармака на цю тему подібна:

Покажчики NULL є найбільшою проблемою в C / C ++, принаймні, у нашому коді. Подвійне використання єдиного значення як прапорця, так і адреси викликає неймовірну кількість фатальних проблем. Посилання на C ++ повинні надаватися переваги покажчикам, коли це можливо; в той час як посилання є "дійсно" лише вказівником, це неявний договір бути не-NULL. Виконайте перевірку NULL, коли покажчики перетворюються на посилання, після цього ви можете ігнорувати проблему.

http://www.altdevblogaday.com/2011/12/24/static-code-analysis/

Редагувати 2012-03-13

Користувач Брет Кунс правильно зауважує:

Стандарт C ++ 11 завершено. Я думаю, що настав час у цій темі згадати, що більшість кодів має чудово поєднуватись із поєднанням посилань, shared_ptr та unique_ptr.

Це правда, але питання все ще залишається навіть при заміні необроблених покажчиків на розумні покажчики.

Наприклад, обидва std::unique_ptrі std::shared_ptrможуть бути сконструйовані як "порожні" вказівники через конструктор за замовчуванням:

• http://en.cppreference.com/w/cpp/memory/unique_ptr/unique_ptr
• http://en.cppreference.com/w/cpp/memory/shared_ptr/shared_ptr

... це означає, що використання їх без перевірки, що вони не порожні, ризикує аварією, саме про це і йдеться в дискусії Дж. Кармака.

І тоді у нас є кумедна проблема "як ми передаємо розумний покажчик як параметр функції?"

Jon «сек відповідь на питання C ++ - надіслати адресу підвищення :: shared_ptr , і наступні коментарі показують , що навіть тоді, передаючи смарт - покажчик на копію або за посиланням не настільки чіткого зрізу , як хотілося б (я схвалюю себе в" посилання "за замовчуванням, але я можу помилитися).

Це не питання смаку. Ось кілька остаточних правил.

Якщо ви хочете звернутися до статично оголошеної змінної в межах, в якій вона була оголошена, тоді використовуйте посилання C ++, і це буде абсолютно безпечно. Це ж стосується і статично оголошеного інтелектуального вказівника. Приклад цього використання параметрів за допомогою посилання є прикладом цього використання.

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

Ви можете посилатися на елемент колекції з посиланням на синтаксичну зручність, але це не безпечно; елемент можна видалити в будь-який час.

Щоб безпечно зберігати посилання на елемент колекції, ви повинні використовувати посилальний підрахунок інтелектуального вказівника.

Будь-яка різниця в ефективності була б настільки мала, що не виправдовуватиметься менш зрозумілим підходом.

По-перше, один випадок, про який не згадувалося, коли посилання, як правило, вище, - це constпосилання. Для непростих типів введення const referenceсимволу уникає створення тимчасового та не викликає непорозумінь, які вас турбують (оскільки значення не змінюється). Тут змушення людини передавати вказівник викликає саме непорозуміння, про яке ви хвилюєтесь, оскільки перегляд взятої та переданої адреси функції може змусити вас думати, що значення змінилося.

У будь-якому випадку я в основному з вами згоден. Мені не подобається, що функції, посилаючись на посилання, змінюють їх значення, коли не дуже очевидно, що саме ця функція робить. Я теж вважаю за краще використовувати в цьому випадку покажчики.

Коли вам потрібно повернути значення складного типу, я, як правило, віддаю перевагу посиланням. Наприклад:

bool GetFooArray(array &foo); // my preference
bool GetFooArray(array *foo); // alternative

Тут ім'я функції дає зрозуміти, що ви отримуєте інформацію в масиві. Так що плутанини немає.

Основні переваги посилань полягають у тому, що вони завжди містять дійсне значення, чистіші за покажчики та підтримують поліморфізм, не потребуючи зайвих синтаксисів. Якщо жодна з цих переваг не застосовується, немає жодної причини віддавати перевагу посиланню на покажчик.

Скопійовано з вікі -

Наслідком цього є те, що в багатьох реалізаціях робота зі змінною з автоматичним або статичним терміном експлуатації через посилання, хоча синтаксично схожа на доступ до неї безпосередньо, може залучати приховані операції дереференції, які є дорогими. Посилання є синтаксично суперечливою особливістю C ++, оскільки вони затьмарюють рівень непрямості ідентифікатора; тобто на відміну від коду С, де покажчики зазвичай виділяються синтаксично, у великому блоці коду С ++ це може бути не відразу зрозуміло, якщо об'єкт, до якого звертається, визначений як локальна чи глобальна змінна чи чи є посилання (неявний покажчик) на деяке інше місце, особливо якщо код змішує посилання та покажчики. Цей аспект може зробити важко написаний код C ++ важчим для читання та налагодження (див. Псевдонім).

Я з цим на 100% погоджуюся, і саме тому я вважаю, що ви повинні використовувати посилання лише тоді, коли у вас є дуже вагомі причини для цього.

Бали, які слід пам’ятати:

1. Покажчики можуть бути NULL, посилання не можуть бути NULL.

2. Посилання простіше у використанні, constїх можна використовувати для довідки, коли ми не хочемо змінювати значення і просто потрібна посилання у функції.

3. Покажчик, який використовується в *той час, як посилання використовуються з a &.

4. Використовуйте покажчики, коли потрібна арифметична операція вказівника.

5. Ви можете мати покажчики на тип пустоти, int a=5; void *p = &a;але не може мати посилання на тип недійсності.

Вказівник проти посилання

void fun(int *a)
{
    cout<<a<<'\n'; // address of a = 0x7fff79f83eac
    cout<<*a<<'\n'; // value at a = 5
    cout<<a+1<<'\n'; // address of a increment by 4 bytes(int) = 0x7fff79f83eb0
    cout<<*(a+1)<<'\n'; // value here is by default = 0
}
void fun(int &a)
{
    cout<<a<<'\n'; // reference of original a passed a = 5
}
int a=5;
fun(&a);
fun(a);

Вирок, коли використовувати що

Вказівник : для масиву, списку посилань, реалізації дерев та арифметики вказівника.

Довідка : Параметри функцій та типи повернення.

Існує проблема з правилом " використовувати посилання, де це можливо ", і вона виникає, якщо ви хочете зберегти посилання для подальшого використання. Щоб проілюструвати це прикладом, уявіть, що у вас є наступні класи.

class SimCard
{
    public:
        explicit SimCard(int id):
            m_id(id)
        {
        }

        int getId() const
        {
            return m_id;
        }

    private:
        int m_id;
};

class RefPhone
{
    public:
        explicit RefPhone(const SimCard & card):
            m_card(card)
        {
        }

        int getSimId()
        {
            return m_card.getId();
        }

    private:
        const SimCard & m_card;
};

Спочатку може здатися, що параметр у RefPhone(const SimCard & card)конструкторі передається посиланням, оскільки це перешкоджає передачі неправильних / нульових покажчиків на конструктор. Це якимось чином заохочує розподіл змінних у стеці та отримання переваг від RAII.

PtrPhone nullPhone(0);  //this will not happen that easily
SimCard * cardPtr = new SimCard(666);  //evil pointer
delete cardPtr;  //muahaha
PtrPhone uninitPhone(cardPtr);  //this will not happen that easily

Але тоді тимчаси приходять знищити ваш щасливий світ.

RefPhone tempPhone(SimCard(666));   //evil temporary
//function referring to destroyed object
tempPhone.getSimId();    //this can happen

Тож якщо ви сліпо дотримуєтесь посилань, ви скасовуєте можливість передачі недійсних покажчиків на можливість зберігання посилань на знищені об'єкти, що в основному має такий же ефект.

редагувати: Зауважте, що я дотримувався правила "Використовуйте посилання, де можна, вказівники, куди потрібно. Уникайте покажчиків, поки не зможете". з найбільш схваленої та прийнятої відповіді (інші відповіді також пропонують це). Хоча це має бути очевидним, приклад - не показувати, що посилання як такі погані. Однак їх можна неправомірно використовувати, як і вказівники, і вони можуть створювати власні загрози коду.

Існують такі відмінності між вказівниками та посиланнями.

1. Що стосується передачі змінних, pass by reference виглядає як pass by value, але має семантику покажчика (діє як покажчик).
2. Посилання не можна безпосередньо ініціалізувати до 0 (null).
3. Посилання (посилання, не посилається на об'єкт) не можна змінювати (еквівалентно покажчику "* const").
4. const посилання може приймати тимчасовий параметр.
5. Місцеві посилання на const продовжують термін експлуатації тимчасових об'єктів

Враховуючи ці мої діючі правила, наступне.

• Використовуйте посилання на параметри, які будуть використовуватися локально в межах функції.
• Використовуйте покажчики, коли 0 (null) є прийнятним значенням параметра або вам потрібно зберегти параметр для подальшого використання. Якщо 0 (null) прийнятний, я додаю до параметра суфікс "_n", використовуйте захищений покажчик (наприклад, QPointer у Qt) або просто документуйте його. Ви також можете використовувати розумні покажчики. Ви повинні бути обережнішими зі спільними вказівниками, ніж із звичайними вказівниками (інакше ви можете закінчитись дизайном витоків пам'яті та безладдям).

Нижче наведено деякі вказівки.

Функція використовує передані дані, не змінюючи їх:

1. Якщо об’єкт даних малий, наприклад вбудований тип даних або мала структура, передайте його за значенням.

2. Якщо об’єктом даних є масив, використовуйте вказівник, тому що це ваш єдиний вибір. Зробіть покажчик покажчиком на const.

3. Якщо об'єкт даних має структуру великого розміру, використовуйте const покажчик або посилання const для підвищення ефективності програми. Ви економите час і простір, необхідні для копіювання структури або дизайну класу. Зробіть покажчик або посилання const.

4. Якщо об'єкт даних є об'єктом класу, використовуйте const-посилання. Семантика дизайну класів часто вимагає використання посилання, що є основною причиною того, що C ++ додав цю функцію. Отже, стандартний спосіб передачі аргументів об’єкта класу є посиланням.

Функція змінює дані у викликовій функції:

1. Якщо об'єкт даних є вбудованим типом даних, використовуйте вказівник. Якщо ви помітите код на зразок fixit (& x), де x є int, цілком зрозуміло, що ця функція має намір змінити x.

2. Якщо об'єкт даних є масивом, використовуйте єдиний вибір: вказівник.

3. Якщо об'єкт даних є структурою, використовуйте посилання або вказівник.

4. Якщо об'єкт даних є об’єктом класу, використовуйте посилання.

Звичайно, це лише вказівки, і можуть бути причини, щоб робити різний вибір. Наприклад, cin використовує посилання на основні типи, щоб ви могли використовувати cin >> n замість cin >> & n.

Довідники чистіші та простіші у використанні, і вони краще допомагають приховувати інформацію. Однак, посилання не можуть бути перепризначені Якщо вам потрібно спочатку вказати на один об’єкт, а потім на інший, потрібно скористатися вказівником. Посилання не можуть бути нульовими, тому, якщо існує якийсь шанс, що відповідний об'єкт може бути недійсним, не слід використовувати посилання. Потрібно використовувати вказівник. Якщо ви хочете самостійно обробляти маніпуляції з об'єктом, тобто якщо ви хочете виділити простір пам’яті для об’єкта в Heap, а не на стеці, ви повинні використовувати покажчик

int *pInt = new int; // allocates *pInt on the Heap

Ви повинні мати такий приклад, як правильно написаний

void add_one(int& n) { n += 1; }
void add_one(int* const n)
{
  if (n)
    *n += 1;
}

Ось чому посилання краще, якщо це можливо ...

Тільки я поставив свій грош. Я щойно провів тест. Підлий у цьому. Я просто дозволяю g ++ створювати файли складання тієї ж міні-програми за допомогою покажчиків порівняно з використанням посилань. Якщо дивитися на вихід, вони точно однакові. За винятком символіки. Отож, дивлячись на продуктивність (на простому прикладі) немає жодної проблеми.

Тепер на тему покажчиків проти посилань. ІМХО Я думаю, що чіткість стоїть понад усе. Як тільки я читаю неявну поведінку, пальці ніг починають скручуватися. Я погоджуюсь, що приємно неявна поведінка, що посилання не може бути NULL.

Перенаправлення покажчика NULL не є проблемою. це призведе до збоїв у вашій програмі та буде легко налагоджувати. Більшою проблемою є неініціалізовані покажчики, що містять недійсні значення. Це, швидше за все, призведе до пошкодження пам’яті, що спричинить невизначеність поведінки без чіткого походження.

Тут я думаю, що посилання набагато безпечніші, ніж покажчики. І я погоджуюся з попереднім твердженням, що інтерфейс (який повинен бути чітко зафіксований, див. Дизайн за контрактом, Бертран Мейєр) визначає результат параметрів функції. Тепер, беручи до уваги все це, мої переваги переходять до використання посилань, де / коли це можливо.

Для вказівників вам потрібно, щоб вони вказували на щось, тому вказівники коштують місця в пам'яті.

Наприклад, функція, яка приймає цілочисельний покажчик, не буде приймати цілу змінну. Тож вам потрібно буде створити вказівник для того, щоб спочатку перейти до функції.

Що стосується довідки, то це не буде коштувати пам'яті. У вас є ціла змінна, і ви можете передавати її як опорну змінну. Це воно. Вам не потрібно створювати довідкову змінну спеціально для неї.