Здравствуйте, alzt, Вы писали:
A>Здравствуйте, FDSC, Вы писали:
FDS>>Здравствуйте, alzt, Вы писали:
A>Выглядит не проще, не думаю, что в логике моего примера (корявого, как выяснилось выше — торопился) разобраться будет сложнее.
Выглядит не проще только потому что мой пример работает, а ваш — нет. И ещё мой пример обладает большей функциональностью, чем ваш
Уровень простоты примерно одинаков. Может быть у меня немного сложнее, но именно немного.
Зато не надо будет потом разбираться, что какой класс дружественный, какой не дружественный. Можно изменять класс C без всяких побочных эффектов на класс интерфейса.
Поэтому мой пример точно проще с точки зрения стратегической
Здравствуйте, alzt, Вы писали:
A>Здравствуйте, igna, Вы писали:
I>>Здравствуйте, alzt, Вы писали:
A>>>VS2005 отлично компилирует
I>>Да, но вроде не должен, поскольку GetIterator пытается вернуть объект абстрактного класса I. Давай заменим на I* GetIterator()?
A>Понял почему он компилируется: GetIterator() я не определяю, а насчёт класса I — в момент определения класса C о нём ничего не известно (что он абстрактный). Надо указатель возвращать.
A>Проверить пока не могу — а в C# подобный пример скомпилируется?
В C# нет дружественных классов. Это, кстати, тема топика
Здравствуйте, FDSC, Вы писали:
A>>Проверить пока не могу — а в C# подобный пример скомпилируется?
FDS>В C# нет дружественных классов. Это, кстати, тема топика
Здравствуйте, alzt, Вы писали:
A>Здравствуйте, FDSC, Вы писали:
A>>>Проверить пока не могу — а в C# подобный пример скомпилируется?
FDS>>В C# нет дружественных классов. Это, кстати, тема топика
A>Я имел ввиду этот пример
Здравствуйте, Sinclair, Вы писали:
V>>В базовом фреймворке процент использования этой "концепции" зашкаливает за 50%, по моему субъективному наблюдению. Т.е. кол-во internal типов не уступает кол-ву публичных типов. S>Гм. Не совсем так: интернальность классов никакого отношения к "дружбе" не имеет. Классы внутри сборки не имеют никакого особого доступа к членам интернал-классов.
Звучит как оксюморон. Именно тот самый "особый" доступ и имеют. С т.з. ограничения доступа public член internal типа вовсе не то же самое что public для public.
Про friend я и не утверждал, что это совсем одно и то же, было сказано про аналоги, которые позволяют решать те же задачи, для чего придуман friend.
S>А интернал поля (которые были бы аналогом friend+private) применяются гораздо-гораздо реже.
Не только поля, полно еще методов и св-в internal в публичных классах фреймворка. А когда вижу internal члены у internal классов, то вообще ощущение как от неубранного мусора, но это всё уже частности, остающиеся на совести разработчиков фреймворка.
Здравствуйте, vdimas, Вы писали: V>Звучит как оксюморон. Именно тот самый "особый" доступ и имеют.
Ну нет же. В С++ friend имеет доступ ко всем приватным членам своего друга. Это вызывает зависимость от реализации, а не от публичного контракта. Интернальные классы устроены совершенно по-другому — они вообще скрыты от всех, кроме соседей по сборке. При этом эти соседи все равно могут пользоваться исключительно публичным интерфейсом.
V>Не только поля, полно еще методов и св-в internal в публичных классах фреймворка. А когда вижу internal члены у internal классов, то вообще ощущение как от неубранного мусора, но это всё уже частности, остающиеся на совести разработчиков фреймворка.
По-моему, это издержки декомпилятора. Если я не ошибаюсь, он все public мемберы интернал классов показывает как internal. А internal полей я что-то не припомню.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Ну нет же. В С++ friend имеет доступ ко всем приватным членам своего друга. Это вызывает зависимость от реализации, а не от публичного контракта. Интернальные классы устроены совершенно по-другому — они вообще скрыты от всех, кроме соседей по сборке. При этом эти соседи все равно могут пользоваться исключительно публичным интерфейсом.
Во-первых, хорошим тоном в С++ считается, чтобы френды не лезли к полям, а лишь оперировали некоторыми приватными методами, что можно расценить по твоей терминологии как "публичный интерфейс внутри сборки". ИМХО, в С++ просто не стали раздувать иерархию доступа friend, обошлись минимально достаточным механизмом.
А во-вторых, что-то в последнее время всё сложнее беседовать в rsdn из-за предположения, будто собеседник чего-то там не знает.
Я акцентировался на задачах, т.е. вопрос стоит так: зачем вообще давать доступ к приватным членам в С++? Так вот, повторюсь, именно для этих самых задач internal подходит превосходно, тем более, что internal могут быть не только классы целиком, но и отдельные члены классов. В С++ получается предоставление доступа "наоборот" из-за самого способа распространения программ. Например, если мы распространяем бинарно, например, lib/dll-файлы и только h-заголовки к ним, то из всех этих h-заголовков перед распространением можно вообще убрать все объявления friend.
И еще, насчет зависимостей (маленький offtop) какие-то ограничение ВНУТРИ модуля — это уже даже несмешно, это клиника на мой взгляд. Я понимаю, когда речь идёт о монстрообразных базовых сборках, изготовляемыми десятками незнакомых программистов, но прикладные должны быть такого объема, дабы понятие "модуль" не потеряло свой компонентный смысл.
V>>Не только поля, полно еще методов и св-в internal в публичных классах фреймворка. А когда вижу internal члены у internal классов, то вообще ощущение как от неубранного мусора, но это всё уже частности, остающиеся на совести разработчиков фреймворка. S>По-моему, это издержки декомпилятора. Если я не ошибаюсь, он все public мемберы интернал классов показывает как internal.
Нет, именно по-разному.
S>А internal полей я что-то не припомню.
С т.з. ограничения доступа public член internal типа вовсе не то же самое что public для public. 
