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

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


A>>вложенные классы == деталь реализации,

K>Это не более чем ваша точка зрения. Более того ваша точка зрения не совпадает с официальной политикой партии.

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

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

A>Я попробую ещё раз перефразировать свою мысль. Вложенные классы — это деталь реализации. Вынос их наружу пользователям завязывает пользователей вложенных классов на знания об охватывающем классе, что им вообще никак не нужно, более того, никакой связи между ними и быть не должно. Ещё раз — в случае вложенных классов использование класса как неймспейса — порочная практика, т.к. повышает связность кода там, где её не должно быть.

С чего вы взяли, что вложенный класс — это деталь реализации и порочный подход? Ведь всё ровно наоборот, в соответствии с классической концепцией ООП, вложенные классы описывают специфичные для данного типа объекты которыми он может обмениваться с внешним миром. Вынося вложенные классы во внешнее пространство имён мы разрываем внутреннюю связность кода, тем самым усложняя его чтение. Более того, внутренняя связность объект-сообщение присуща не только типам, но и функциям вот обсуждение

Автор: B0FEE664
Дата: 08.10.15

.

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

В теме 56 очков оценок. Пипец во что RSDN скатился.

Очкуют даже откровенную лажу.
Пора валить.

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

В общем понятно, у вас есть собственное убеждение по поводу вложенных классов. Спорить чьё ООП правильнее у меня желания нет.

A>>>Ну и про "Several details still need to be worked out." ты и сам написал.

PM>>Я лишь процитировал мнение заседателей в комитете. От них трудно ожидать другого — в таком legacy проекте как С++ первой реакцией на любое предложение может быть только поморщить лоб и изречь вышеотквоченное.
A>Хм. Копипастил не читая? В твоей цитате вполне конкретные issues приведены: what happens if a definition of X does not appear in any other translation unit (TU)? What happens if a definition of X appears in another TU, but does not define a nested class A? What happens if it does define a nested class A, but it’s private?
A>У тебя есть ответы на эти вопросы?

Копипастил читая. Рекомендую погрепать стандарт языка на словосочетания "implementation-defined behavior", "undefined behavior", "unspecified behavior" чтобы узнать предполагаемые ответы.

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

K>Это не более чем ваша точка зрения. Более того ваша точка зрения не совпадает с официальной политикой партии. В stl использование типов объявленных внутри классов носит массовый характер. И деталями реализации их не назовешь. Открываем к примеру map, и что мы видим?

я уже написал выше про STL, почему там это ни на что не влияет и как я к этому отношусь.

Я немного разовью мысль. Насчёт шаблонов, мой поинт в том, что там вложенные классы в паблике ни на что не влияют. В шаблонах и так все внутренности наружу. Насчёт нешаблонных классов мой поинт в том, что помещение inner класса в паблик секцию создаёт ненужную зависимость в коде. Например с точки зрения товарища B0FEE664, если я правильно понял его мысль, какой-нибудь класс, реализующий например парсинг протокола, будет содержать описание классов распарсенных пакетов внутри себя как inner class, потому что по сути только он один их конструирует, и это по сути его "сообщения" во внешний мир. Я же считаю подобный подход говнокодом ошибкой дизайна. Т.к. пользователям этих сообщений не всегда необходимо напрямую работать с парсером, соответственно нужды в знаниях о нём нет. А использование вложенных классов такую осведомлённость форсируют.

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

BFE>С чего вы взяли, что вложенный класс — это деталь реализации и порочный подход?
Я написал выше про итераторы и отсутствие нужды в знаниях о классе контейнера вообще

BFE>Ведь всё ровно наоборот, в соответствии с классической концепцией ООП, вложенные классы описывают специфичные для данного типа объекты которыми он может обмениваться с внешним миром.
классическое ООП и прочие абстрактные вещи меня не очень интересуют, я о больше о насущном, о зацепленности кода.

>Вынося вложенные классы во внешнее пространство имён мы разрываем внутреннюю связность кода, тем самым усложняя его чтение.
В том то и дело, что эта зацепленность не нужна. См. пример про итераторы и контейнеры снова.

>Более того, внутренняя связность объект-сообщение присуща не только типам, но и функциям вот обсуждение

Автор: B0FEE664
Дата: 08.10.15

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

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

K>С требованием о закрытии проекта. Язык в котором за тридцать с чем-то лет не сделали опережающее описание для вложенных классов не имеет права на существование.

Эх, ностальгия... Помнится 11 лет назад подобная эпическая тема

Автор: Kluev
Дата: 05.07.05

от тебя была, я еще студентом был. До сих пор не полегчало?

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

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

PM>В общем понятно, у вас есть собственное убеждение по поводу вложенных классов. Спорить чьё ООП правильнее у меня желания нет.

В том то и дело что мне абсолютно безразлично "правильное" понимание ООП или прочей теории кайфа. Я говорю о совершенно приземлённых вещах — возникновении зацепленности кода на ровном месте.

PM>Копипастил читая. Рекомендую погрепать стандарт языка на словосочетания "implementation-defined behavior", "undefined behavior", "unspecified behavior" чтобы узнать предполагаемые ответы.
послал так послал

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

A>В том то и дело что мне абсолютно безразлично "правильное" понимание ООП или прочей теории кайфа. Я говорю о совершенно приземлённых вещах — возникновении зацепленности кода на ровном месте.

В С++ эта борьба может превратится в борьбу с ветрянными мельницами. Язык позволяет выносить объявление вложенного класса за пределы владельца в том числе в другой файл. А то что для использования вложенного класса нужно будет включать описание владельца, за это нужно сказать спасибо создателям языка подложившим свинью в виде препроцессора

struct Outer
{
    struct Inner;

    std::vector<Inner*> items;
};

struct Outer::Inner
{
    int x;
};

void test()
{
    Outer ou;
    Outer::Inner *x = new Outer::Inner();
    ou.items.push_back(x);
}

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

K>И с момента включения stl в стандарт развитие языка пошло в ущерб традиционному ООП. Могли бы хотя бы интерфейсы сделать, как в яве и C#, но нет, комитет занят обслуживанием мелкобуквенных библиотек.
K>В языке полно давно назревших проблем которые нужно было решить еще 20 лет назад. Для примера в паскале от препроцессора отказались еще в 1978 году.

Так Александреску сотоварищи давно все поняли и исправили, и даже название языка стало проще и короче: поскольку совместимость с С была нарушена, следуя заветам semver инкрементировали первую букву, получился D.
А С++ — так это легаси, оставленное для компиляции старого кода.

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

PM>Предложение такое есть: http://wg21.link/p0289r0 и некоторая надежда, что его примут в С++17:
PM>Цитата отсюда: https://botondballo.wordpress.com/2016/03/21/trip-report-c-standards-meeting-in-jacksonville-february-2016/

Но сам же автор и предупреждает о граблях:

Allowing the definition of X::A when X hasn’t been defined, however, would
raise other questions. First, name lookup in a nested class includes name lookup into its
surrounding class, which doesn’t make sense if the surrounding class is incomplete.

class X;
class X::A { … };

Т.е., скомпиллированное тело X::A может сильно отличаться в зависимости от того, был где-то ранее описан X или нет.

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

PM>>Предложение такое есть: http://wg21.link/p0289r0 и некоторая надежда, что его примут в С++17:
PM>>Цитата отсюда: https://botondballo.wordpress.com/2016/03/21/trip-report-c-standards-meeting-in-jacksonville-february-2016/

V>Но сам же автор и предупреждает о граблях:
V>Т.е., скомпиллированное тело X::A может сильно отличаться в зависимости от того, был где-то ранее описан X или нет.

Такие грабли уже есть, ODR violation

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

V>>Но сам же автор и предупреждает о граблях:
V>>Т.е., скомпиллированное тело X::A может сильно отличаться в зависимости от того, был где-то ранее описан X или нет.
PM>Такие грабли уже есть, ODR violation

Дык, в нынешней ситуации для этого (чаще всего) надо написать две разных реализации, а тут шанс получить ODR violation при наличии всего одной. Принципиальная разница, ИМХО.