константная, технически этот код вполне корректен. Понятно, что клиент может использовать эту функцию
GetBuffer
для того, чтобы изменить объект
String
множеством разных способов, не прибегая к явному преобразованию типов. Например,
strcpy(s.GetBuffer, "Very Long String...")
— вполне законный код; любой компилятор пропустит его без каких бы то ни было замечаний. Если бы мы объявили возвращаемый тип как
const char*
, то представленный код вызвал бы, по крайней мере, ошибку времени компиляции, так что случайно поступить столь опасно было бы просто невозможно — вызывающий код должен был бы использовать явное преобразование типов (см.
рекомендации 92 и 95).
Но даже возврат указателей на
const
не устраняет возможности случайного некорректного использования, поскольку имеется еще одна проблема, связанная с корректностью внутренних данных класса. В приведенном выше примере с классом
String
, вызывающий код может сохранить значение, возвращаемое функцией
GetBuffer
, а затем выполнить операции, которые приведут к росту (и перемещению) буфера
String
, что в результате может привести к использованию сохраненного, но более недействительного указателя на несуществующий в данный момент буфер. Таким образом, если вы считаете, что у вас есть причины для обеспечения такого доступа ко внутреннему состоянию, вы должны детально документировать, как долго возвращаемое значение остается корректным и какие операции делают его недействительным (сравните с гарантиями корректности явных итераторов стандартной библиотеки; см. [C++03]).
Исключения
Иногда классы обязаны предоставить доступ ко внутренним дескрипторам по причинам, связанным с совместимостью, например, для интерфейса со старым кодом или при использовании других систем. Например,
std::basic_string
предоставляет доступ к своему внутреннему дескриптору посредством функций-членов
data
и
c_str
для совместимости с функциями, которые работают с указателями С — но не для того, чтобы хранить эти указатели и пытаться выполнять запись с их помощью! Такие функции доступа "через заднюю дверь" всегда являются злом и должны использоваться очень редко и очень осторожно, а условия корректности возвращаемых ими дескрипторов должны быть точно документированы.
С++ делает закрытые члены недоступными, но не невидимыми. Там, где это оправдывается получаемыми преимуществами, следует подумать об истинной невидимости, достигаемой применением идиомы Pimpl (указателя на реализацию) для реализации брандмауэров компилятора и повышения сокрытия информации (см. рекомендации 11 и 41).
Обсуждение
Когда имеет смысл создать "брандмауэр компилятора", который полностью изолирует вызывающий код от закрытых частей класса, воспользуйтесь идиомой Pimpl (указателя на реализацию): скройте их за непрозрачным указателем (указатель (предпочтительно подходящий интеллектуальный) на объявленный, но пока не определенный класс). Например:
class Map {
// ...
private:
struct Impl;
shared_ptr<Impl> pimpl_;
};
Дающий название идиоме указатель должен использоваться для хранения всех закрытых членов, как данных, так и закрытых функций-членов. Это позволяет вам вносить произвольные изменения в закрытые детали реализации ваших классов без какой бы то ни было рекомпиляции вызывающего кода. Свобода и независимость — вот отличительные черты рассматриваемой идиомы (см. рекомендацию 41).
Примечание: объявляйте указатель на закрытую реализацию, как показано — с использованием двух объявлений. Если вы скомбинируете две строки с предварительным объявлением типа и указателя на него в одну инструкцию
struct Impl *pimpl;
это будет вполне законно, но изменит смысл объявления: в этом случае
Impl
находится в охватывающем пространстве имен и не является вложенным типом вашего класса.
Имеется как минимум три причины для использования Pimpl, и все они вытекают из различия между доступностью (в состоянии ли вы вызвать или использовать некоторый объект) и видимостью (видим ли этот объект для вас и, таким образом, зависите ли вы от его определения) в С++. В частности, все закрытые члены класса недоступны никому, кроме функций- членов и друзей, но зато видимы всем — любому коду, которому видимо определение класса.
Первое следствие этого — потенциально большее время сборки приложения из-за обработки излишних определений типов. Для закрытых данных-членов, хранящихся по значению, и параметров закрытых функций-членов, передаваемых по значению или используемых в видимой реализации функций, типы должны быть определены, даже если они никогда не потребуются в данной единице компиляции. Это может привести к увеличению времени сборки, например:
class C {
// ...
private:
AComplicatedType act_;
}
Заголовочный файл, содержащий определение класса С, должен также включать заголовочный файл, содержащий определение
AComplicatedType
, который в свою очередь транзитивно включает все заголовочные файлы, которые могут потребоваться для определения
AComplicatedType
, и т.д. Если заголовочные файлы имеют большие размеры, время компиляции может существенно увеличиться.
Второе следствие — создание неоднозначностей и сокрытие имен для кода, который пытается вызвать функцию. Несмотря на то, что закрытая функция-член не может быть вызвана кодом вне ее класса и его друзей, она тем не менее участвует в поиске имен и разрешении перегрузки и тем самым может сделать вызов неоднозначным или некорректным. Перед выполнением проверки доступности С++ выполняет поиск имен и разрешение перегрузки. Из-за этого видимость имеет более высокий приоритет:
int Twice(int); // 1
class Calc {
public:
string Twice(string); // 2
private:
char* Twice(char*); // 3
int Test {
return Twice(21); // A: ошибка, функции 2 и 3 не
// подходят (могла бы подойти функция 1, но
// ее нельзя рассматривать, так она скрыта от
// данного кода)
}
};
Calc с;
с.Twice("Hello"); // Б: ошибка, функция 3
// недоступна (могла бы использоваться
// функция 2, но она не рассматривается, так
// как у функции 3 лучшее соответствие
// аргументу)
В строке А обходной путь состоит в том, чтобы явно квалифицировать вызов как
::Twice(21)
для того, чтобы заставить поиск имен выбрать глобальную функцию. В строке Б обходной путь состоит в добавлении явного преобразования типа
с.Twiсе(string("Hellо"))
для того, чтобы заставить разрешение перегрузки выбрать соответствующую функцию. Некоторые из таких проблем, связанных с вызовами, можно решить и без применения идиомы Pimpl, например, никогда не используя закрытые перегрузки функций-членов, но не для всех проблем, разрешимых при помощи идиомы Pimpl, можно найти такие обходные пути.