Неоднозначность shared_from_this

Цитата D_KEY @ 02.10.12, 11:45

Эм. Мы о поиске имен.

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

Добавлено 02.10.12, 11:48
Иными словами наследники и клиенты класса и так не защищены от изменения приватной части. Так чего ты ещё хочешь?

Цитата MyNameIsIgor @ 02.10.12, 11:47

Цитата D_KEY @ 02.10.12, 11:45

Эм. Мы о поиске имен.

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

Так "видь" размер. Какое это отношение имеет к доступности имен?

Цитата D_KEY @ 02.10.12, 11:44

Автор C ничего не знает о private-частях своих предков. Иначе это не private.

В том то и дело, что знает. И в этом отличительная черта объектой модели Плюсов. Ты можешь обойти инкапсуляцию, если очень надо, и иначе никак. Это будет говнокод, но не всё говнокод, что так выглядит, иногда говнокодом является не он сам, а его основополагающая база, и написанный тобой говнокод - это едиственный способ решить проблему. В случее PImpl такого в принципе невозможно будет сделать. Выбор как всегда на нами, а не языком.

Цитата D_KEY @ 02.10.12, 11:49

Так "видь" размер. Какое это отношение имеет к доступности имен?

Так они не доступны Ты не можешь их вызвать и обратиться к ним.

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

Цитата D_KEY @ 02.10.12, 11:51

Клиенту должны быть недоступны имена из закрытой части.

Они и так недоступны! Ты же хочешь, чтобы они были невидимы. Т.е. превратить спецификаторы доступа в спецификаторы видимости.

Цитата MyNameIsIgor @ 02.10.12, 11:49

Цитата D_KEY @ 02.10.12, 11:49

Так "видь" размер. Какое это отношение имеет к доступности имен?

Так они не доступны Ты не можешь их вызвать и обратиться к ним.

Недоступны мемберы. А имена - доступны. См. мой пример с неоднозначностью из-за добавления закрытого метода в базовый класс.
Представь себе SFINAE с выбором специализации, допустим, по наличию внутреннего типа. Если у тебя будет соответствующий private-тип то SFINAE просто не сработает, а код не скомпилируется... Хотя надо попробовать

Цитата D_KEY @ 02.10.12, 11:54

Недоступны мемберы. А имена - доступны.

Так вот и давай говорить о доступности и о видимости, ok?

Цитата D_KEY @ 02.10.12, 11:54

Представь себе SFINAE с выбором специализации, допустим, по наличию внутреннего типа. Если у тебя будет соответствующий private-тип то SFINAE просто не сработает, а код не скомпилируется...

Да, я в курсе. И?

Цитата MyNameIsIgor @ 02.10.12, 11:55

Цитата D_KEY @ 02.10.12, 11:54

Недоступны мемберы. А имена - доступны.

Так вот и давай говорить о доступности и о видимости, ok?

Имена-то доступны Ладно, ок, давно плюсовую литературу не читал

Цитата

Да, я в курсе. И?

Почему это правильно(если в интерфейсе класса этого самого внутреннего типа нет) и ради чего, собственно?

Цитата D_KEY @ 02.10.12, 11:58

Почему это правильно(если в интерфейсе класса этого самого внутреннего типа нет) и ради чего, собственно?

Нужно освежить по D&E, там этому не мало посвящено.
Просто мне кажется это логичным при механизме текстовых include'ов - мы и так всё видим, зачем делать вид, что нет?

Цитата MyNameIsIgor @ 02.10.12, 12:01

Нужно освежить по D&E, там этому не мало посвящено.

Да, я вот тоже вспомнить не могу... Сегодня посмотрю

Цитата

Просто мне кажется это логичным при механизме текстовых include'ов - мы и так всё видим, зачем делать вид, что нет?

Потому, что это делает менее логичным поиск имен.

Цитата D_KEY @ 02.10.12, 12:03

Потому, что это делает менее логичным поиск имен.

Вот у тебя возникали серьёзные проблемы или ты только сейчас так разошёлся?

Цитата MyNameIsIgor @ 02.10.12, 12:04

Вот у тебя возникали серьёзные проблемы

Неа. Но я вообще не помню, чтобы мне как-то помогали private/protected/public. Это же не повод...