Здравствуйте, Kluev, Вы писали: K>С требованием о закрытии проекта. Язык в котором за тридцать с чем-то лет не сделали опережающее описание для вложенных классов не имеет права на существование.
Не знаю, где первоисточник, поэтому просто процитирую:
Тыц
Пацаны, я тут короче сидел за монитором и попытался скомпилить какую-то шнягу из буста, не помню какую, но внезапно компилятор сказал мне «интернал еррор» много раз. И тут я вдруг задумался — какое же говно c++! <[ апплодисменты в зале ]>
Представляете, пацаны, он дает мне stdio и iostream, и я должен выбирать. А как я выберу, это же так сложно, прямо глаза разбегаются! А вдруг я использую и первое, и второе? Совсем беспредел же получится, пацаны, видите какой говно-язык? <[ зал продолжает рукоплескать ]>
А стандартная библиотека? Она же просто ужасна! Там даже строки кривые — не спрашивайте почему, я не знаю^W^W^Wэто же очевидно! И знаете, скажу вам по секрету, я открыл ее исходник... Да, исходник самой stl! Вот вы когда-то смотрели туда? Вижу по глазам, что не смотрели. А я вот посмотрел, и ничего там не понял!!! <[ Бурное проявление недовольства в зале, апплодисменты, крики «Страуструпа на мыло!» ]>
Вот смотрите сюда, пацаны. Я нашел кусок кода, в котором используются макросы с шаблонами, конструкторы бросают исключения, написана куча велосипедных аллокаторов, память течет как из ведра. Я читал его и ужасался, на каком же говно-языке все вокруг пишут! <[ Одинокий голос из зала «а может ты сам написал этот код?», раздается несколько ударов, несогласного выносят ]>
И инкапсуляция у них нарушается всегда!!! В только представьте, пацаны — они спят и видят, как бы ее нарушить! Просыпаются, и сразу же бегут ее нарушать; засыпают, мечтая о том, как пойдут нарушать ее завтра! <[ Дамы в зале утираются платочками, всхлипывая; мужчины сидят с каменными лицами, сцепив зубы ]>
И вообще, самое страшное — этот подлый язык заставляет меня думать! Думать над освобождением памяти, думать yад нормальной иерархией классов, думать над всем!!! Так дальше продолжаться не может — пора закопать его! За-ко-пать!!! Такое говно не должно оскорблять своим существованием наш священный мирок! Кто со мной?!
<[ Все, сидящие в зале, вскакивают, словно распрямившаяся пружина, и выбегают в дверь следом за лидером. Кажется, старому язычку пришел п****ц. Армия скрывается в тумане, некоторое время оттуда слышатся крики «Батт-хёрт! Батт-хёрт! Батт-хёрт!», под которые марширует этот карательный отряд, потом и они затихают вдали ]>
Из потайной дверцы в опустевший зал входит Александреску, вертя в руках блокнот. «2011 год, реактивное говно-нашествие школоты номер 9681», записывает он туда; выходит из зала, запирая дверь на ключ. На крыльце его поджидает Страуструп, они заходят в соседний паб, заказывают по кружке темного пива, и с улыбкой смотрят на экран на стене.
На том экране виден гигантский небоскреб с двумя крестами на крыше, вокруг которого бегают мелкие на его фоне людишки, стуча кулаками в стены. Но стены почему-то не пробиваются; атакующие разбивают костяшки в кровь, и обиженно отходят, дуя на окровавленные пальцы. Вместо них к стенам пробиваются новые фанатики, но их становится все меньше; волна постепенно угасает.
«больше двадцати лет прошло, и все повторяется», — со вздохом говорит Бьёрн, потягивая пиво.
К небоскребу достраивают еще один этаж, новый подземный паркинг. Отбитые пальцы горе-разрушителей почти зажили.
«Пацаны...», — начинает свою проповедь очередной мессия.
С требованием о закрытии проекта. Язык в котором за тридцать с чем-то лет не сделали опережающее описание для вложенных классов не имеет права на существование.
Здравствуйте, SaZ, Вы писали:
SaZ>Не знаю, где первоисточник, поэтому просто процитирую:
Фигня полная. Обычно неопытный программист относится к с++ и его библиотекам более лояльно, т.к. еще не знает, что его ждет. Начинающий думает, что библиотеки языка спроектированы опытными программистами и вышли из реальных проектов, хотя в действительности iostream была написана на спор, а stl экспериментальная исследовательская разработка.
С stl в С++ вообще началась эпоха мелкобуквенного говнокода
И с момента включения stl в стандарт развитие языка пошло в ущерб традиционному ООП. Могли бы хотя бы интерфейсы сделать, как в яве и C#, но нет, комитет занят обслуживанием мелкобуквенных библиотек.
В языке полно давно назревших проблем которые нужно было решить еще 20 лет назад. Для примера в паскале от препроцессора отказались еще в 1978 году.
Здравствуйте, Kluev, Вы писали:
K>С требованием о закрытии проекта. Язык в котором за тридцать с чем-то лет не сделали опережающее описание для вложенных классов не имеет права на существование.
Здравствуйте, Kluev, Вы писали:
K>С требованием о закрытии проекта. Язык в котором за тридцать с чем-то лет не сделали опережающее описание для вложенных классов не имеет права на существование.
и ещё тридцать лет не сделают. Это одна из немногих встроенных защит от говнокода.
Это не более чем ваша точка зрения. Более того ваша точка зрения не совпадает с официальной политикой партии. В stl использование типов объявленных внутри классов носит массовый характер. И деталями реализации их не назовешь. Открываем к примеру map, и что мы видим?
key_type Key
mapped_type T
value_type std::pair<const Key, T>
size_type Беззнаковый целочисленный тип (обычно size_t)
difference_type Знаковый целочисленный тип (обычно std::ptrdiff_t)
key_compare Compare
allocator_type Allocator
reference Allocator::reference (до C++11)
value_type& (начиная с C++11)
const_reference Allocator::const_reference (до C++11)
const value_type& (начиная с C++11)
pointer Allocator::pointer (до C++11)
std::allocator_traits<Allocator>::pointer (начиная с C++11)
const_pointer Allocator::const_pointer (до C++11)
std::allocator_traits<Allocator>::const_pointer (начиная с C++11)
iterator BidirectionalIterator
const_iterator Константный двусторонний итератор
reverse_iterator std::reverse_iterator<iterator>
const_reverse_iterator std::reverse_iterator<const_iterator>
Все эти типы предназначены для использования снаружи и никак не могут считатся деталями реализации.
Здравствуйте, Kluev, Вы писали:
K>С требованием о закрытии проекта. Язык в котором за тридцать с чем-то лет не сделали опережающее описание для вложенных классов не имеет права на существование.
Ты можешь не пользоваться им. А ему (и страусу и языку) будет по прежнему плевать на тебя. А остальным пользоваться не мешай.
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, SaZ, Вы писали:
SaZ>>Не знаю, где первоисточник, поэтому просто процитирую:
K>Фигня полная...
Воспринимайте это как художественную литературу.
K>И с момента включения stl в стандарт развитие языка пошло в ущерб традиционному ООП. Могли бы хотя бы интерфейсы сделать, как в яве и C#, но нет, комитет занят обслуживанием мелкобуквенных библиотек. K>В языке полно давно назревших проблем которые нужно было решить еще 20 лет назад. Для примера в паскале от препроцессора отказались еще в 1978 году.
Многие идеи Вирта воплощены в различных языках, в том числе в C# / Java. Но это не значит, что тот же паскаль без пропроцессора займёт какую-то конкретную нишу.
Мне кажется, что всему своё время. Не хочу разводить холивар, но меня очень радует направление и темпы, как развивается С++ сейчас. Дайте ему немного времени и при всей гибкости и мощности С++ будет очень эффективным языком широкого профиля.
Здравствуйте, PM, Вы писали:
PM>А почему использование вложенных классов является признаком говнокода? Я понимаю топикстартера, накипело. Буквально на днях занимался вынесением публичного вложенного класса наружу, пришлось создать для него и для исходного класса новое пространство имен, чтобы использовать предварительное объявление в другом месте.
вложенные классы == деталь реализации, использовать деталь реализации снаружи == говнокод. Топикстартер хочет в говнокод добавить варенья, но не принимает во внимание то, что сам подход — порочный. Кивать в сторону STL и прочего не надо. Во-первых там шаблоны, они в любом случае выставляют внутренности наружу, так что разница не велика. А во-вторых особого смысла делать те же итераторы nested классами я не вижу, разница между vector<T>::iterator и iterator<vector<T>> мне не очевидна, принимаю существующую форму просто как исторически сложившийся факт. Ну и про "Several details still need to be worked out." ты и сам написал.
Здравствуйте, Kluev, Вы писали:
K>С требованием о закрытии проекта. Язык в котором за тридцать с чем-то лет не сделали опережающее описание для вложенных классов не имеет права на существование.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Kluev, Вы писали:
K>>С требованием о закрытии проекта. Язык в котором за тридцать с чем-то лет не сделали опережающее описание для вложенных классов не имеет права на существование.
Q>В мире есть ещё языки, где хоть кого-то волнует «опережающее описание для вложенных классов»?
А в мире еще есть языки в которых интерфейс к гландам предоставляется строго через задницу?
Я имею ввиду использование препроцессора для доставки деклараций конпелятору.
Здравствуйте, antropolog, Вы писали:
K>>С требованием о закрытии проекта. Язык в котором за тридцать с чем-то лет не сделали опережающее описание для вложенных классов не имеет права на существование.
A>и ещё тридцать лет не сделают. Это одна из немногих встроенных защит от говнокода.
А почему использование вложенных классов является признаком говнокода? Я понимаю топикстартера, накипело. Буквально на днях занимался вынесением публичного вложенного класса наружу, пришлось создать для него и для исходного класса новое пространство имен, чтобы использовать предварительное объявление в другом месте.
Forward declarations of nested classes. This would allow things like X::A* to appear in a header without requiring a definition for X to also appear in the header (forward-declarations of X and X::A will be sufficient). EWG found the use case compelling, because currently a lot of class definitions to appear in headers only because interfaces defined in the header use pointers or references to nested classes of the type. Several details still need to be worked out. (For example, 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? The answer to some or all of these may have to be “ill-formed, no diagnostic required”, because diagnosing errors of this sort would require significant linker support.)
Здравствуйте, antropolog, Вы писали:
PM>>А почему использование вложенных классов является признаком говнокода? Я понимаю топикстартера, накипело. Буквально на днях занимался вынесением публичного вложенного класса наружу, пришлось создать для него и для исходного класса новое пространство имен, чтобы использовать предварительное объявление в другом месте.
A>вложенные классы == деталь реализации, использовать деталь реализации снаружи == говнокод. Топикстартер хочет в говнокод добавить варенья, но не принимает во внимание то, что сам подход — порочный. Кивать в сторону STL и прочего не надо. Во-первых там шаблоны, они в любом случае выставляют внутренности наружу, так что разница не велика. А во-вторых особого смысла делать те же итераторы nested классами я не вижу, разница между vector<T>::iterator и iterator<vector<T>> мне не очевидна, принимаю существующую форму просто как исторически сложившийся факт.
Вложенный класс может быть публичным. Тогда это уже не деталь реализации, а интерфейса, и я не вижу в этом ничего противоестественного.
Да, это сахар и проблему можно решить переносом вложенного класса на уровень пространства имен. Но если улучшать язык, то почему бы это не сделать? Объявление вложенных пространств имен в C++17 уже включили. По-моему, добавление похожей возможности для классов сделает язык более согласованным.
A>Ну и про "Several details still need to be worked out." ты и сам написал.
Я лишь процитировал мнение заседателей в комитете. От них трудно ожидать другого — в таком legacy проекте как С++ первой реакцией на любое предложение может быть только поморщить лоб и изречь вышеотквоченное.
PM>Вложенный класс может быть публичным. Тогда это уже не деталь реализации, а интерфейса, и я не вижу в этом ничего противоестественного.
в том то и дело, что это не интерфейс, а отдельная сущность. Например в случае с итераторами. Мне вообще нет дела до того, как он внутри устроен, и уж тем более мне нет дела до самого класса вектора. То что приватные классы можно выставлять в паблик секцию это недоработка. Сравнимая примерно с наличием protected секции.
PM>Да, это сахар и проблему можно решить переносом вложенного класса на уровень пространства имен. Но если улучшать язык, то почему бы это не сделать? Объявление вложенных пространств имен в C++17 уже включили. По-моему, добавление похожей возможности для классов сделает язык более согласованным.
Я попробую ещё раз перефразировать свою мысль. Вложенные классы — это деталь реализации. Вынос их наружу пользователям завязывает пользователей вложенных классов на знания об охватывающем классе, что им вообще никак не нужно, более того, никакой связи между ними и быть не должно. Ещё раз — в случае вложенных классов использование класса как неймспейса — порочная практика, т.к. повышает связность кода там, где её не должно быть.
A>>Ну и про "Several details still need to be worked out." ты и сам написал.
PM>Я лишь процитировал мнение заседателей в комитете. От них трудно ожидать другого — в таком legacy проекте как С++ первой реакцией на любое предложение может быть только поморщить лоб и изречь вышеотквоченное.
Хм. Копипастил не читая? В твоей цитате вполне конкретные 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?
У тебя есть ответы на эти вопросы?
Здравствуйте, antropolog, Вы писали:
A>Я попробую ещё раз перефразировать свою мысль. Вложенные классы — это деталь реализации. Вынос их наружу пользователям завязывает пользователей вложенных классов на знания об охватывающем классе, что им вообще никак не нужно, более того, никакой связи между ними и быть не должно. Ещё раз — в случае вложенных классов использование класса как неймспейса — порочная практика, т.к. повышает связность кода там, где её не должно быть.
С чего вы взяли, что вложенный класс — это деталь реализации и порочный подход? Ведь всё ровно наоборот, в соответствии с классической концепцией ООП, вложенные классы описывают специфичные для данного типа объекты которыми он может обмениваться с внешним миром. Вынося вложенные классы во внешнее пространство имён мы разрываем внутреннюю связность кода, тем самым усложняя его чтение. Более того, внутренняя связность объект-сообщение присуща не только типам, но и функциям вот обсуждение
Здравствуйте, Kluev, Вы писали:
K>И с момента включения stl в стандарт развитие языка пошло в ущерб традиционному ООП. Могли бы хотя бы интерфейсы сделать, как в яве и C#, но нет, комитет занят обслуживанием мелкобуквенных библиотек. K>В языке полно давно назревших проблем которые нужно было решить еще 20 лет назад. Для примера в паскале от препроцессора отказались еще в 1978 году.
Так Александреску сотоварищи давно все поняли и исправили, и даже название языка стало проще и короче: поскольку совместимость с С была нарушена, следуя заветам semver инкрементировали первую букву, получился D.
А С++ — так это легаси, оставленное для компиляции старого кода.
Здравствуйте, Kluev, Вы писали:
K>С требованием о закрытии проекта. Язык в котором за тридцать с чем-то лет не сделали опережающее описание для вложенных классов не имеет права на существование.
В мире есть ещё языки, где хоть кого-то волнует «опережающее описание для вложенных классов»?
Здравствуйте, T4r4sB, Вы писали:
TB>Здравствуйте, Kluev, Вы писали:
K>>И с момента включения stl в стандарт развитие языка пошло в ущерб традиционному ООП.
TB>И правильно. Кому нужны абстрактные фабрики виртуальных методов — го на жабу. А мы на шаблонах всё статически разрулим.
забавно от вас, постоянно недовольного с++, такое слышать
Здравствуйте, Kluev, Вы писали:
K>Здравствуйте, antropolog, Вы писали:
A>>вложенные классы == деталь реализации,
K>Это не более чем ваша точка зрения. Более того ваша точка зрения не совпадает с официальной политикой партии.
это даже не политика партии, а просто здравый смысл, подсказывающий собирать до кучи все то, что имеет смысл использовать только совместно.
В общем понятно, у вас есть собственное убеждение по поводу вложенных классов. Спорить чьё ООП правильнее у меня желания нет.
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>Ведь всё ровно наоборот, в соответствии с классической концепцией ООП, вложенные классы описывают специфичные для данного типа объекты которыми он может обмениваться с внешним миром.
классическое ООП и прочие абстрактные вещи меня не очень интересуют, я о больше о насущном, о зацепленности кода.
>Вынося вложенные классы во внешнее пространство имён мы разрываем внутреннюю связность кода, тем самым усложняя его чтение.
В том то и дело, что эта зацепленность не нужна. См. пример про итераторы и контейнеры снова.
>Более того, внутренняя связность объект-сообщение присуща не только типам, но и функциям вот обсуждение
.
я пока не читал и мысль мне не понятна. Но попахивает какой-то абстрактной теорией ООП, я же говорю о совершенно практических вещах, практически всегда все вынесенные в паблик inner классы могут (должны) использоваться без знаний об enclosed классах, но язык этого не позволяет, и провоцирует возникновение зацепленности на ровном месте.
Здравствуйте, PM, Вы писали:
PM>Здравствуйте, antropolog, Вы писали:
PM>В общем понятно, у вас есть собственное убеждение по поводу вложенных классов. Спорить чьё ООП правильнее у меня желания нет.
В том то и дело что мне абсолютно безразлично "правильное" понимание ООП или прочей теории кайфа. Я говорю о совершенно приземлённых вещах — возникновении зацепленности кода на ровном месте.
PM>Копипастил читая. Рекомендую погрепать стандарт языка на словосочетания "implementation-defined behavior", "undefined behavior", "unspecified behavior" чтобы узнать предполагаемые ответы.
послал так послал
Здравствуйте, antropolog, Вы писали:
A>В том то и дело что мне абсолютно безразлично "правильное" понимание ООП или прочей теории кайфа. Я говорю о совершенно приземлённых вещах — возникновении зацепленности кода на ровном месте.
В С++ эта борьба может превратится в борьбу с ветрянными мельницами. Язык позволяет выносить объявление вложенного класса за пределы владельца в том числе в другой файл. А то что для использования вложенного класса нужно будет включать описание владельца, за это нужно сказать спасибо создателям языка подложившим свинью в виде препроцессора
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 или нет.
Здравствуйте, PM, Вы писали:
V>>Но сам же автор и предупреждает о граблях: V>>Т.е., скомпиллированное тело X::A может сильно отличаться в зависимости от того, был где-то ранее описан X или нет. PM>Такие грабли уже есть, ODR violation
Дык, в нынешней ситуации для этого (чаще всего) надо написать две разных реализации, а тут шанс получить ODR violation при наличии всего одной. Принципиальная разница, ИМХО.
