Разрешено ли использовать переменную-член передаваемого объекта класса аргумента при определении функции-члена класса? [Дубликат]

Трюк заключается в том, чтобы помнить, что данные private относятся к классу, а не к экземпляру класса. Любой метод внутри вашего класса может получить доступ к личным данным любого экземпляра этого класса; не существует способа держать данные конфиденциальными внутри экземпляра, если вы не запрещаете методы, которые явно получают доступ к частным данным из других экземпляров.

Это несколько решение по выбору языка. В Ruby , например, private действительно означает private, как в «только экземпляр может обращаться к своим собственным частным данным». Однако это несколько ограничивает.

Как указано в комментариях, конструкторы копирования и операторы присваивания являются общими местами, где вы напрямую обращаетесь к частным частным данным другого экземпляра. Есть менее очевидные причины.

Рассмотрим следующий случай. Вы реализуете связанный список OO. Связанный список имеет класс вложенных узлов для управления указателями. Вы можете реализовать этот класс узлов таким образом, чтобы он управлял самими указателями (вместо того, чтобы указатели были общедоступны и управлялись списком). В таком случае у вас будут объекты узлов, которые хотят изменить указатели других узлов объектов в других местах, которые типичны для конструктора копирования и оператора присваивания.

Так как это работает на C ++. В C ++ управление доступом работает на основе per-class , а не на основе каждого объекта.

Управление доступом в C ++ реализовано как статическая функция времени компиляции. Я думаю, что довольно очевидно, что на этапе компиляции реально невозможно реализовать какой-либо значимый контроль доступа к каждому объекту. Этот способ может быть реализован только для каждого класса.

Некоторые рекомендации по управлению объектами присутствуют в спецификации protected access , поэтому он даже имеет свою собственную выделенную главу в стандарт (11.5). Но все же описанные там характеристики каждого объекта довольно рудиментарны. Опять же, управление доступом на C ++ предназначено для работы на основе класса.

Это хороший вопрос, и я недавно столкнулся с этим вопросом. У меня были некоторые дискуссии с моими коллегами, и вот резюме нашего обсуждения: Это по дизайну. Это не означает, что этот дизайн является полностью разумным для всех случаев, но должны быть некоторые соображения, почему выбрано для каждого класса. Возможные причины, о которых мы могли подумать, включают:

. Прежде всего, стоимость контроля доступа к экземпляру может быть очень высокой. Об этом говорили другие в этой теме. Теоретически это можно сделать с помощью этой проверки указателя . Однако это невозможно сделать во время компиляции и может быть выполнено только во время выполнения. Таким образом, вам нужно определить контроль доступа каждого участника во время выполнения, а когда он будет нарушен, возможно, будут затронуты только исключения. Стоимость высокая.

Во-вторых, для контроля доступа к классу имеет свой собственный прецедент, например, конструктор копирования или оператор =. Было бы сложно реализовать их, если контроль доступа на один экземпляр.

Кроме того, управление доступом в основном связано с перспективой программирования / языка, как модулировать / управлять доступом к коду / члену, а не данных.

В дополнение ко всем приведенным выше ответам рассмотрите конструкторы специальных копий, операторы присваивания и все другие функции, которые вы должны написать для класса, которые работают с другими экземплярами . Вам понадобятся функции доступа для всех этих элементов данных.

«Частный» на самом деле не является механизмом контроля доступа в смысле «Я сделал свои фотографии на facebook частным, чтобы вы их не видели».

В C ++, «private» просто говорит, что это части класса, которые вы (кодер класса) могли бы изменить в будущих версиях и т. Д., И вы не хотите, чтобы другие кодеры, использующие ваш класс, полагались на их существование или функциональность.

Если вам нужен настоящий контроль доступа, вы должны внедрить подлинные методы защиты данных.

Частные данные остаются закрытыми до тех пор, пока кто-то, у кого есть доступ к нему, не обнаружит его другим.

Эта концепция применима и к другой ситуации, например:

class cMyClass
{
public:
   // ...
   // omitted for clarity
   // ...

   void Withdraw(int iAmount)
   {
      iTheSecretVault -= iAmount;
   }

private:
   int iTheSecretVault;
};

снимать деньги? :) [/ Д2]