Здравствуйте, so5team, Вы писали:

S>Здравствуйте, Sm0ke, Вы писали:

S>>Здравствуйте, so5team, Вы писали:

S>>>Не уверен, что вы поняли меня, но уверен, что не понял вас.

S>>Отдельный внутренний класс internal_env_iface_t можно поместить в private: часть другого класса.
S>>Таким образом можно разграничить использование этого internal_env_iface_t
S>>В си++ есть такая возможность. В этом может помочь nested classes
S>>https://en.cppreference.com/w/cpp/language/nested_types

S>Вот это и заставляет меня думать, что вы не поняли меня.
S>Если делать internal_env_iface_t закрытым, то чтобы дать к нему доступ из разных мест придется эти разные места прописывать в качестве друзей. А именно этого и хочется избежать.

Ну как понимаю класть всех использующих internal_env_iface_t в один большой nest не предлагать?

Но можно же наследовать nest-ы!
Положить использующих internal_env_iface_t по своим разным nest-ам,
Те nest-ы отнаследовать от nest-а, в котором лежит internal_env_iface_t как protected:

Вот и уменьшилось число friend указаний.
Да, я теоретизирую. Да, на практике могут быть нюансы.

И кстати стоило бы проверить: Если в качестве friend указан nest, то nested классы получат ли доступ тоже? А их наследники?

--

Такие штуки вообще могут быть решены через модули, партишены и выборочный экспорт имён.

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, Sm0ke, Вы писали:

S>>Здравствуйте, so5team, Вы писали:

S>>>Не уверен, что вы поняли меня, но уверен, что не понял вас.

S>>Отдельный внутренний класс internal_env_iface_t можно поместить в private: часть другого класса.
S>>Таким образом можно разграничить использование этого internal_env_iface_t
S>>В си++ есть такая возможность. В этом может помочь nested classes
S>>https://en.cppreference.com/w/cpp/language/nested_types

S>Вот это и заставляет меня думать, что вы не поняли меня.
S>Если делать internal_env_iface_t закрытым, то чтобы дать к нему доступ из разных мест придется эти разные места прописывать в качестве друзей. А именно этого и хочется избежать.

Ну как понимаю класть всех использующих internal_env_iface_t в один большой nest не предлагать?

Но можно же наследовать nest-ы!
Положить использующих internal_env_iface_t по своим разным nest-ам,
Те nest-ы отнаследовать от nest-а, в котором лежит internal_env_iface_t как protected:

Вот и уменьшилось число friend указаний.
Да, я теоретизирую. Да, на практике могут быть нюансы.

И кстати стоило бы проверить: Если в качестве friend указан nest, то nested классы получат ли доступ тоже? А их наследники?
upd: Answer "nested классы" да; 'их наследники' нет;

--

Такие штуки вообще могут быть решены через модули, партишены и выборочный экспорт имён.