Ошибки, баги, вопросы - страница 1056
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
1. Если Вы действительно хотите спрятать свой кошелёк, то зачем делаете функцию gч() ?
2. А при копировании экземпляров имеются?
Читай предыдущий мой пост. Там все ответы.
Когда-то в древности, было принято "политическое решение" считать другие объекты (экземпляры) собственного класса френдами "по умолчанию" - чисто для экономии букаф. А ты теперь это исключение считаешь за норму жизни и до кучи хочешь беспрепятственно лазить по частным карманам всех дальних родственников.
Гы...
1. Помещение в приватную часть ничего не изменит в случае
При наследовании изменит, это понятно.
2. Мало чего кому понадобится... основания имеются только при доступе к собственному экземпляру.
3. Ну так и пусть решает. Корректно. ;)
4. Вот весь вопрос в том и состоит: что именно считать "корректной работой".
Ок. А скажи мне. Как определить в классе такое поле, чтоб его можно было модифицировать только и исключительно методами именно экземпляра "хозяина" и ничьими другими.
Если это невозможно, тогда видимо тема сисек инкапсуляции в языке не раскрыта. Не?
Ок. А скажи мне. Как определить в классе такое поле, чтоб его можно было модифицировать только и исключительно методами именно экземпляра "хозяина" и ничьими другими.
Если это невозможно, тогда видимо тема сисек инкапсуляции в языке не раскрыта. Не?
Эта особенность неприятно удивила. Однозначно это херь полная, если компилятор позволяет менять приватное поле чужого экземпляра. Надо бы в сервисдеск запостить.
Я не пойму: вы для чего так хотите сами себя ограничить?
Думаете от этого ваша программа автоматически станет безопаснее?
Не станет! Скорее даже наоборот.
Именно лишние ограничения заставят вас когда-нибудь написать так:
Кошелёк это всего лишь частный случай. И никто не мешает поместить его в приватную часть.
В другом случае может понадобиться доступ к переменной родительского класса чужого объекта.
И это должен программист решать, разрешать или нет. А компилятор должен обеспечить корректную работу программы.
В том-то и дело, если у Вас возникает этот самый другой случай, то значит Ваша архитектура концептуально неверна и потенциально опасна.
В С++ в свое время была введена неудачная концепция т.к. называемых дружественных классов. Типа если один класс знает как устроен другой, то он вполне безопасно может работать с его внутренними данными. Практика использования тысячами программистов по всему миру показала что это опасная вещь, создающая больше проблем, чем решающая, поэтому в современных языках вроде Java и C# от нее отказались.
Эта особенность неприятно удивила. Однозначно это херь полная, если компилятор позволяет менять приватное поле чужого экземпляра. Надо бы в сервисдеск запостить.