Если вы осуществляете копирование при записи, вам вообще не следует определять эти операторы подписки. Клиенту, который вызывает const
версию метода подписки для объекта x
, не разрешается впоследствии использовать эту ссылку для изменения компонента x
, но ссылка все равно должна отражать изменения, которые вносят другие клиенты ( этот компонент) x
. Но это не произойдет со стратегией копирования при записи, поскольку изменение будет происходить не в той копии, на которую указывают ссылки.
Также два клиента, которые вызывают неконстантный оператор подписки с одним и тем же индексом, должны получать (изменяемые) ссылки на один и тот же data
объект; но они этого не сделают, потому что при вызове операторов подписки будут сделаны две отдельные копии.
Вместо этого у вас может быть метод подписки, который возвращает data
по значению. Это позволяет избежать иллюзии получения псевдонима для компонента x
(который, как я утверждал, должен быть иллюзорным при реализации копирования при записи). Вы также можете предоставить один метод, который изменяет компонент x
(вместо разделения этой операции на подписку с последующим назначением полученной ссылки), который либо внутренне делает копию, либо просто изменяет компонент на месте, если эта копия была уже сделана. Это скрыло бы от клиентов использование реализации копирования при записи.
В более общем смысле, раскрытие методов, которые возвращают ссылки на внутренние объекты, независимо от того, const
или нет, - это раскрытие деталей реализации того, что такие объекты существуют вообще. Это ограничивает свободу изменения реализации позже, например, для сжатия данных или для их хранения в другом месте, чем в памяти.