Есть класс Б, который является friend'ом класса A. У класса А есть несколько private параметорв.
Вопрос: стоит ли какая-то угроза безопасности доступа к private'ам класса А? Ведь по сути - private'ы - нужны для того, чтобы закрыть нежелательный запрос к определённым параметрам, а тут его открывают  

Дружественный класс имеет доступ к private секции класса.

Что такое нежелательный запрос?

 А друзья нужны что бы его открыть   Поскольку дружественные функции и класс требуют указания в описании класса, которое доступно только разработчику, а не пользователю этого класса, то никакой угрозы нет. ( Главное ведь скрыть поля от прямого изменения пользователем   )

Это сообщение отредактировал(а) Sartorius - 23.1.2007, 17:34

Пользователю доступно описание класса. А если возьмет и вставит строчку friend... Или перенесет переменные из одной секции в другую? Линкер разве ругнется?

Anikmar, конечно может, он может вообще ехе-шник в нех-редакторе подправить. Ведь секции private и protected создаются не для того чтобы усложнить пользователю жизнь, а совсем наооборот, чтобы показать какие методы ему следует использовать, а какие используются для внутренних нужд. Если он откроет доступ. то никто ругаться естественно не будет.

Не знаю ругнется ли линкер, если поменять описание класса(добавить какого нибудь друга).  (скорее всего нет , так как это дело только компилятора) Менять h-ник можно сколько угодно, но ведь что бы реально можно было вызывать эту дружественную функцию , нада все перекомпилировать. А без реализации класса этого не сделать...   

Добавлено @ 18:02 
 Присоединяюс к  zkv. Секции - это не борьба за копирайт и т.п., а средство, которое позволяет превратить логические ошибки в синтаксические

zkv, Совершенно согласен. Секции предназначены для самоконтроля и дисциплины.

Этот вопросик я задал перекликаясь с первым постом:


Пользователю нельзя ничего запретить - если захочет, все равно влезет. А вот сказать заранее, куда лезть не надо - это да.

По-моему друзья придуманы для запоздалого исправления ошибок в проектировании класса 

Добавлено @ 18:05 

Вот я и спросил - ругнется линкер или нет?
Перкомпиляция самого класса не нужна, просто находятся ли члены из приват-секции в таблице символов линкера?

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

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

Думаю  есть очень много оснований для использования друзей в более общем случае.

пользователь? всмысле тот что кнопы жмакает?  от такого вообще ничего не скроешь, все поломает! 


то есть объявить друга можно было а дописать метод, который бы обращался к приватным полям нельзя было?

Именно так. Класс вызывал форму, которая при закрытии должна была обнулить указатель на саму себя. Было лень писать метод - так как таких форм было порядка 10 (изначально ошибся в выборе стратегии - думал они будут модальные, а оказалось что неудобно работать)
Чем писать 10 методов (ну лень мне стало!) я обявил 10 форм друзьями.   

ИМХО Работает и ладно! - не для преподавателя, для себя пишу.

В данном случае пользователь это программист, при чем тут тот кто кнопки жмет

KelTron, при том, что тот кто кнопки жмет, в состоянии поломать абсолютно все =)

Добавлено @ 03:15 
KelTron, вообще любое сообщение стоит рассматривать в контексте 

Если изменить доступ, но не перекомпилировать библиотеку, то да: реальные имена включают модификаторы доступа, по крайней мере в MSVC. На добавление friend - нет.


С таким подходом быстро допишешься...

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

выходил ещё пример: модель ассоциативной операции. например, вычисление силы притяжения между двумя объектами. если делать методом, принимающим в качестве аргумента второй объект, то надо будет сделать в классе доступ к данным о массе, которая другими классами востребована не будет. но, даже если захламленность пространства имен свойствами, используемыми разово, не волнует, то есть ещё проблема логики: от какого объекта отталкиваться? почему при вычислении силы притяжения между Землей и Солнцем надо использовать метод объекта Солнце? разве Земля не притягивает Солнце?! А функция таких вопросов не вызывает - два аргумента; оба равноправные...

Ну-ну... по принципу - вроде, работает и ладно. Ты часто занимался поддержкой и модификацией подобного кода (особенно чужого)?
Это очень плохой подход, поверь...

Я про конкретно указанный случай.
Модификации там быть не может - существует класс, существует документация по методам и свойствам, нечего туда лазить.
Если понадобится модифицировать форму - на указанный участок это никак не повлияет.
Если понадобится добавить новую форму - аналогично (не повлияет).

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

В других случаях, кроме указанного, мне не доводилось использовать друзей класса - всегдя старался обойтись методами класса (и свойствами билдера).



Как раз очень правильный принцип. Работает правильно - не лезь! Иначе работа над проектом превратится в постоянную оптимизацию. Оптимизацию начинай в новой версии продукта, когда старая версия уже работает.

skyboy, дык это не friend-функция, а просто глобальная функция, принимающая объекты. Нет необходимости напрямую лезть и изменять члены-данные участников солнечной системы.


такое ощущение, что вас это распухание радует  


То есть есть класс-менеджер форм, в котором содержится указатель на форму, и формы должны иметь возможность его менять?

Добавлено @ 22:03 
В одной из подчиненных форм создаем метод, принимающий объект класса-менеджера и изменяющий указатель в нем при помощи get/set класса-менеджера. Остальные 9 форм наследуем.

если имеется ввиду перегрузка то это стандартная техника. как раз для



У тебя есть класс A. Класс B пишет сосед Вася Пупкин. Класс B объявлен другом в твоем классе A.  Пришедши домой после корпоративной вечеринки, Вася Пупкин садится за компьютер и устанавливает переменную size твоего массива в -1000.

Добавлено @ 22:20 
А еще лучше, если Вася установит размер массива в -1000 при снятии третьей снизу галки на пятой вкладке твоего приложения. Тогда о новом размере массива узнает уже пользователь  

Это смех сквозь слезы. Нисколечко не радует - так как конца и края нет, а хотелось бы, чтобы хоть что-то заработало. Погоня за универсализмом и всеохватыванием подвела...

Где-то так. Класс содержит логически законченный объет. Есть набор форм, которые позволяют им управлять. При завершении работы форма должна об этом сообщить классу. Из простых методов пришло на ум два: вызов метода класса, если необходимо предпринять дополнительные действия и тупой обнуление указателя на форму, если таковых действий не нужно (например, для форм диагностики). Со стороны "пользователя" можно пользоваться только методами, например ShowSatistic, следовательно сам указатель на форму пользователю видеть не надо, он в protected секции. Вот и родилась идея "друга" чтобы не писать кучу методов из одной строчки F_StatShow = NULL...

Сейчас я такой подход изменил - я в форму при инициализации передаю адрес переменной, которую надо обнулить. Но старые участки остались с такой реализацией.