необов'язкові вказівники порівняно з не-const посиланнями на C ++

В Інші функції C ++ Reference Аргументи про керівництві Google C ++ Style , я прочитав , що неконстантние посилання не повинні бути використані.

Усі параметри, передані посиланням, повинні бути позначені const.

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

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

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

Обґрунтування посібника зі стилю Google - це просто зрозуміти з сайту виклику функції, чи є параметр вхідним параметром або вихідним параметром. (Див. Тут для подальшого обговорення.) Інші мови визначають параметри, явні за дизайном; Наприклад, у C # є outключове слово, яке необхідно використовувати на сайті виклику . Оскільки C ++ не робить це явним, Google вирішив використовувати const ref. проти вказівника, щоб це було зрозуміло.

Це лише правило Google? Ні, але я сумніваюся, що це дуже широко. Я не думаю, що я бачив це поза посібником зі стилів Google та групами, які чітко дотримуються частин посібника зі стилів Google. (Наприклад, мені сподобалась ідея, коли я вперше прочитав посібник зі стилів Google років тому і використав її для свого власного коду.)

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

Основні настанови C ++ мають кілька великих імен (Bjarne Stroustrup, Herb Sutter), які підтримуються корпорацією Майкрософт, і містять найновіші функції C ++ (на відміну від посібника зі стилів Google), тому я очікую, що його рекомендації будуть популярнішими, ніж Google.

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

Перевірка проста, як:

void foo(void* buffer){
    if(buffer == nullptr)
        return;

    //actually foo

    // note no increase in indentation required

}

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

Це зводиться до вашого спостереження If an output parameter is required.

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

Внутрішньо ви уникаєте вихідних параметрів, розширюючи тип повернення як складовий з усіх "аутів"