Когда лучше использовать ссылки, а когда - указатели
Опытные программисты безоговорочно отдают предпочтение ссылкам, а не указателям. Ссылки проще использовать, и они лучше справляются с задачей сокрытия информации, как вы видели в предыдущем примере.
Но ссылки нельзя переназначать. Если же вам нужно сначала указывать на один объект, а затем на другой, придется использовать указатель. Ссылки не могут быть нулевыми, поэтому, если существует хоть какая-нибудь вероятность того, что рассматриваемый объект может быть нулевым, вам нельзя использовать ссылку. В этом случае необходимо использовать указатель.
В качестве примера рассмотрим оператор new. Если оператор new не сможет выделить память для нового объекта, он возвратит нулевой указатель. А поскольку ссылка не может быть нулевой, вы не должны инициализировать ссылку на эту память до тех пор, пока не проверите, что она не нулевая. В следующем примере показано, как это сделать:
int *pInt = new int;
if (pInt != NULL)
int &rInt = *pInt;
В этом примере объявляется указатель pInt на значение типа int, который инициализируется областью памяти, возвращаемой оператором new. Адрес этой области памяти (в указателе pInt) тестируется, и, если он не равен значению null, указатель pInt разыменовывается. Результат разыменования переменной типа int представляет собой объект типа int, и ссылка rInt инициализируется этим объектом. Следовательно, ссылка rInt становится псевдонимом для переменной типа int, возвращаемой оператором new.
Рекомендуется: Передавайте функциям параметры как ссылке везде, где это возможно. Обеспечивайте возврат значений как ссылок везде, где это возможно. Используйте спецификатор const для защиты ссылок и указателей везде, где это возможно.
Не рекомендуется: Не используйте указатели, если вместо них можно использовать ссылки. Не возвращайте ссылки на локальные объекты.
Коктейль из ссылок и указателей
Не будет ошибкой в списке параметров одной функции объявить как указатели, так и ссылки, а также объекты, передаваемые как значения, например:
CAT * SomeFunction (Person &theOwner, House *theHouse, int age);
Это объявление означает, что функция SomeFunction принимает три параметра. Первый является ссылкой на объект типа Person, второй — указателем на объект типа House, а третий — целочисленным значением. Сама же функция возвращает указатель на объект класса CAT.
Следует также отметить, что при объявлении соответствующих переменных можно использовать разные стили размещения операторов ссылки (&) и косвенного обращения (*). Вполне законной будет любая из следующих записей:
1: CAT& rFrisky;
2: CAT & rFrisky;
3: CAT &rFrisky;
Примечание: Символы пробелов в программах на языке C++ полностью игнорируются, поэтому везде, де вы видите пробел, можно ставить несколько пробелов, символов табуляции или символов разрывов строк. Оставив в покое вопросы свободного волеизъявления, попробуем разобраться в том, какой вариант все же лучше других. Как ни странно, можно найти аргументы в защиту каждого из трех вариантов. Аргумент в защиту первого варианта состоит в следующем. rFrisky — это переменная с именем rFrisky, тип которой можно определить как ссылку на объект класса CAT. Поэтому вполне логично, чтобы оператор & стоял рядом с типом.
Однако есть и контраргумент. CAT — это тип. Оператор & является частью объявления, которое включает имя переменной и амперсант. Но следует отметить, что слияние вместе символа & и имени типа CAT может привести к возникновению следующей ошибки:
CAT& rFrisky, rBoots;
Поверхностный анализ этой строки может натолкнуть на мысль, что как переменная rFrisky, так и переменная rBoots являются ссылками на объекты класса CAT. Однако это не так. На самом деле это объявление означает, что rFrisky является ссылкой на объект класса CAT, а rBoots (несмотря на свое имя с характерным префиксом) — не ссылка, а обыкновенная переменная типа CAT. Поэтому последнее объявление следует переписать по-другому:
CAT &rFrisky, rBoots;
В ответ на это возражение стоит порекомендовать, чтобы объявления ссылок и обычных переменных никогда не смешивались в одной строке. Вот правильный вариант той же записи:
CAT& rFrisky; CAT Boots;
Примечание: Наконец, многие программисты не обращают внимания на приведенные аргументы и, считая, что истина находится посередине, выбирают средний вариант (средний, кстати, в двух смыслах), который иллюстрируется случаем 2:
Читать дальше