юнионы в C++

А ещё смеют утверждать, что с++ не зашквар для задротов.

const означает что код обращающийся к переменной с этим модификатором будет обращаться только для чтения и не более того. Это не означает константность объекта и то, что какой-нибудб друго код не будет записывать что-нибудь в жту же переменную

Он даже этого не обозначает. Mutable, static_const, ссылки на non-const, глобальные/static переменные, и просто побочные эффекты — всё это может поменять объект неожиданным образом, даже если я уверен, что мой код обращается к const переменной «только для чтения». Потому const — это именно логическая константность, то есть, то, что мы сами будем понимать под логической константностью в данном случае. Самый что ни на есть комментарий++.

const просто означает что я не буду ничего писать в эту переменную

Хочешь, не хочешь, а придется, бг-г-г.

Он даже этого не обозначает. Mutable, static_const, ссылки на non-const, глобальные/static переменные, и просто побочные эффекты — всё это может поменять объект неожиданным образом, даже если я уверен, что мой код обращается к const переменной «только для чтения».

Это в другую сторону работает: const гарантирует что вызываемая функция не будет менять объект с модификатором const, но если есть другие указатели/ссылки без const, то они без проблем могут менять объект, это так и задумано. const – это защита для вызывающего кода.

Это в другую сторону работает: const гарантирует что вызываемая функция не будет менять объект с модификатором const, но если есть другие указатели/ссылки без const, то они без проблем могут менять объект, это так и задумано. const – это защита для вызывающего кода

Это бы так работало, если бы C++ не был грудой беспорядочно смешанных в кучу фич. В том виде, в котором он сейчас есть, разницу между «код клиента» и «код библиотеки» крайне тяжело уловить, потому что пользовательский код постоянно вызывает код либы, даже приватные поля напрямую инициализирует и финализирует тоже код пользователя. Учитывая mutable и const_cast, const не позволяет априори судить про бинарную константность полей структур — хотя это можно исправить, если все-таки договориться в собственном коде применять const в значении «бинарная константность». То есть, const в среднеарифметическом коде просто значит «для переменных с модификатором const тебе запрещено вызывать функции с аргументом без const».

Так возникает «продажник». При этом byko3y оставляет оппонентам возможность доказать, что дело всё-таки в программистской гениальности. Но вместо этого идёт подсчёт 300 строчек кода

Чем раньше программист поймет, что техническая сторона вопроса не играет никакой роли в IT, тем лучше. В десятый раз я это пишу. Но ты сам снова скатываешься в это заблуждение со своей «программистской гениальностью».

В случае ЯП (да и не только их) на рынке почти всё решается сетевым эффектом, то есть, на языке все пишут потому, что все пишут на этом языке. Есть более одного механизма, который приводит к этому эффекту, но нам важен результат — любое нововведение встречает ожесточенное сопротивление со стороны IT индустрии. Исключение составляют случаи, когда сопротивляться некому — ниша пустая. Вот именно в таких случаях возможно минимальными усилиями создать начальную инерцию, которая сама себя раскрутит, и если в начале девяностых PHP падал в пустую нишу, то в конце девяностых туда уже никто не мог войти. Да, есть примеры Java, .NET, Go, Rust, которые пытались войти в уже освоенные ниши, но там нужны были миллиарды долларов для преодоления инерции.

Теперь перейдем к роли личности. У людей есть склонность искать вождя и идти за вождем. Однако, если ты прикинешь, чего стоит творение Гвидо без TensorFlow, без Numpy, SciPy, Keras, Pandas, то выяснится, что роль Гвидо здесь 0.3%, особенно если учесть, что все эти либы всеми силами стараются избегать всего, что относится к CPython, они реализуют собственные типы данных, собственные функции, даже повторно реализуют функции стандартной библиотеки CPython. Если так подумать, то питон — это просто набор протоколов, вывеска, под которой модно собираться кодерам и работодателям.

Знал ли Гвидо, что он будет лицом этой вывески? Конечно же нет, он бы с радостью ограничился парой десятков человек, с которыми он бы пилил свой проектик, и несколькими тысячами людей, которые бы этим проектом пользовались. В общем-то, на ранних этапах это так и было, и гугл купил дюжину разрабов и пару тысяч пользователей вместо с этой вывеской, чтобы не тратиться на что-то свое. Причем, гугл проиграл в результате этой покупки, поскольку был уверен, что изъяны питона возможно исправить. А оказалось, что невозможно, по крайней мере адекватным числом ресурсов. Ну типа если бы гугл весь свой бюджет бросил на оптимизацию питона, то у него бы получилось, но это не «сэкономить на готовой вывеске», а «купить компанию с миллиардами технического долга».

Если говорить о том, что же общего у Гвидо и Бьерна было для создания этой самой вывески, то это именно стремление всем понравится: «вам не нравится фича? хорошо, исправим, только не бейте», «вам хочется эту функцию? но она же... а ладно, добавим». Гвидо это делал в мейлинг листах, Бьерн тусовался в комитетских кругах. В обоих случаях результатом такой итеративной разработки стал чудовищно плохой с технической стороны, но очень привлекательный с маркетинговой стороны продукт, его легко продать менеджеру, руководителю, кодеру с развитыми софт скилами и социализацией, то есть, теми людьми, которые вносили предложения. По итогу оно хорошо звучит и не работает на практике, потому что отдельных местах технические и маркетинговые требования диаметрально противоположны.

Например, с технической стороны для ЯП обязательно быть простым. С маркетинговой стороны для ЯП обязательно быть как можно более сложным — тогда можно будет больше рассказать про фичи, которые в нем есть. Кстати, именно так был создан PL/I — я только не в курсе, в какой момент и почему он умер. В этом плане питон будет посложнее C++, и не зря за питон больше платят, ведь кол-во ad-hoc решений, которые нужно знать в питоне для разработки машинного обучения, будет поболее, чем в C++.

А комитеты и сообщества разработчиков ещё интереснее. Как получилось, что Гвидо изгнали из сообщества разработчиков Питона? Если всё мерить через программистскую гениальность, то получается, что там остались какие-то более великие гении. Но почему они не так известны, к успеху не пришли?

Я N лет назад читал питоновый мейлинг лист. Обсуждения были плана «будем называть функцию с большой буквы или с маленькой». Короче говоря, сплошной bikeshedding, фундаментальные проблемы никто не решает и не собирается решать. При этом багованная финализация интерпретатора, которую я лично исправил, никого не волнует, поскольку на тестах она не вылазит благодаря грамотно подпертым костылям. Эдакая машина из салона, которая работоспособна ровно настолько, чтобы ее купили и на ней выехали из салона, после чего она немедленно ломается, открываешь капот — а там скрутки, синяя изолента, насквозь ржавый кузов. Это к слову о том, как Гвидо умеет организовывать команду разработки.

Как получилось, что Гвидо изгнали из сообщества разработчиков Питона

Если бы я руководил разработкой питона, то я бы с ума сошел намного раньше, потому что объем техдолга там чудовищен, и в плане спецификации самого языка, которая безумно сложна, и в плане внутренней реализации, с которой работать уже давным давно не просто, и даже многоинтерпретаторы спустя три года так и не смогли сделать — хотя аналогичные штуки давно есть в том же PHP.

Грубо говоря, это как если бы я очень быстро на коленке сделал прототип для показа заказчику в духе «сдам проект, а потом свалю, дальше это не мое дело». Но тут заказчику нравится прототип, и он выдает большой бюджет на дальнейшую разработку, но именно этого прототипа, Потому что заказчику же этот прототип понравился. Тогда я скрипя зубами как-то пытаясь натянуть нужные фичи на кривой прототип. Под маты и слезы кое-как ты все-таки реализуешь нужные фичи за бюджет. Тогда заказчик смотрит на это и говорит «у вас хорошо получается, Будем строить весь интернет на этом». Тут я хватаюсь за голову «ё-ё-ё... вы что там, с ума посходили» — говорю про себя, но также понимаю, что бюджет будет еще больше, отступать мне уже некуда, если я уйду — они найдут другого Гвидо на роль вождя. В какой-то момент я выгораю и в проекте всё становится настолько плохо, что я больше уже не могу и не хочу ничего делать.

развитие Питона сейчас идёт по двум разнонаправленным векторам: с одной стороны надо быть маленьким встраиваемым язычком с динамической типизацией, с другой стороны - серьёзным инструментом для разработки крупных приложений

Я предполагаю, что «развитие» и «питон» нельзя ставить в одном предложении. CPython никогда не станет ни маленьким встраиваемым языком (он огромен и с этим ничего не поделать); ни серьезным инструментом для крупных приложений (фундаментальные сущности в питоне гарантируют, что большой проект рухнет под собственной тяжестью, если это не микросервисы, а микросервисы являются своим собственным классом проблем).

Трудностей на пути в оба направления настолько много и их настолько никто не собирается решать, что проще избавиться от CPython целиком и написать что-то заново. Или, другими словами, взять другой ЯП.

= цикломатическая сложность, E = количество рёбер в графе, N = количество узлов в графе, P = количество компонент связности

Узлы = программные модули; рёбра = зависимости между модулями.

А почему не «узлы — буквы а в исходном коде, ребра — буквы б в исходном коде»? Точно такое же от балды произведенное переопределение значений. Исходная статья на вике вполне ясно говорит, что цикломатическая сложность определяется отклонением от линейного пошагового выполнения, то есть, цикломатическая сложность — число условных переходов в программе. А не модулей.

Функции времени компиляции или кодогенератор.

У автора и так функции времени компиляции и вполне возможно, что он использовал генерацию кода. Так что это всё придирки и вкусовщина, типа рекомендации Crocodoom писать 1_r вместо literal(1). Как будто будет большая разница, если вместо r(1) написать 1_r. Другой вопрос, можно ли циклы генерации запихнуть в constexpr и какие версии компиляторов будут такое поддерживать. Я, например, сталкивался с тем, что нельзя инициализировать константный map, хотя vector без проблем создаётся.

Но вообще, у Crocodoom то был уход от вопроса. eao197 сделал более корректно, показав, что приведённые функции вполне поддаются декомпозиции.

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

и вполне возможно, что он использовал генерацию кода.

В исходниказ не должно быть сгенерированного кода. Генерация кода должна проходить на этапе компиляции. Например Meson позволяет это без проблем делать в том числе и с кодогенератором написанным на C/C++.

Как будто будет большая разница, если вместо r(1) написать 1_r.

Почему не просто {1, 2, 3, …}?

В исходникаx не должно быть сгенерированного кода. Генерация кода должна проходить на этапе компиляции.

Это зависит от ситуации. Если данные мы не собираемся менять (а мы в конкретном случае реализуем классический алгоритм), то зачем нам терять время при каждой компиляции? Вполне можно было просто вынести эту портянку в отдельный файл, чтобы она не мешалась в основном коде.

Почему не просто {1, 2, 3, …}?

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

Эту реализацию какой-то маньяк-перфекционист делал, в хорошем смысле слова. Читается тяжеловато из-за обилия ifdef-ов, inline-ов, функций в одну строчку и прочих ухищрений. Но, вероятно, оптимизировано идеально

Оно плохо оптимизировано в плане скорости, там прям в сорцах сверху написано, что автор вдохновлялся программой, которая победила в соревновании по обфускации:

https://www.ioccc.org/years.html#1996_rcm

Этот оригинал в 5 раз медленнее, чем gzip. Смысл этой программы был в том, чтобы засунуть deflate в минимальное количество символов исходного кода.

Было бы интересно посадить несколько человек «проверить на корректность» оба куска кода, и посмотреть, что они быстрее прочитают:

{auto dtree_fun = state.template DynTreeFunc<bool(Abortable&Flag_InputAbortable)>(std::forward<InputFunctor>(input), ndist, std::forward<BacktrackFunctor>(backtrack), true);
                while(CreateHuffmanTree<bool(Abortable&Flag_InputAbortable)>("Dyn Dists",   state.dtree, ndist, dtree_fun)) { return -2; }}

или же

build_decode_table(
        m_literal_length_decode_table,
        literal_length_table_bits,
        lengths,
        literal_length_values,
        literals_size)

Но ты сам снова скатываешься в это заблуждение со своей «программистской гениальностью».

Не скатываюсь. Просто у тебя гений - это тот, кто может предсказать развитие индустрии на 30 лет вперёд, плюс все эти годы у него есть возможность полностью контролировать развитие своего проекта. У меня требования не такие суровые.

«вам не нравится фича? хорошо, исправим, только не бейте», «вам хочется эту функцию? но она же… а ладно, добавим»

Ну да. Так и есть. Потому что крупными проектами руководят не самые умные в области программирования, а те, у кого есть ресурсы. Это можно критиковать, можно возмущаться, но так будет всегда.

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

А почему не «узлы — буквы а в исходном коде, ребра — буквы б в исходном коде»?

Потому что это не имеет смысла

Исходная статья на вике вполне ясно говорит, что цикломатическая сложность определяется отклонением от линейного пошагового выполнения, то есть, цикломатическая сложность — число условных переходов в программе. А не модулей.

Цикломатическая сложность - это топологическая мера сложности связей орграфа. Строгое опреление я привёл. Предлагаю от него и отталкиваться.

Модули и односторонние зависимости между ними - это орграф, а та чухня, которую ты предложил - это не орграф.

У автора и так функции времени компиляции и вполне возможно, что он использовал генерацию кода. Так что это всё придирки и вкусовщина, типа рекомендации Crocodoom писать 1_r вместо literal(1). Как будто будет большая разница, если вместо r(1) написать 1_r.

Ну так пользовательские литералы для того и ввели, чтобы код был покрасивше. Я никого не заставляю их использовать. Ты же фактически просил code review, разве нет?

Другой вопрос, можно ли циклы генерации запихнуть в constexpr

Можно, очевидно. Вопроса тут никакого нет, constexpr для этого и создавались. Уж констнатные массивы заполнять они должны справиться.

Но вообще, у Crocodoom то был уход от вопроса. eao197 сделал более корректно, показав, что приведённые функции вполне поддаются декомпозиции.

Спасибо за аналитику, однако ты (пока) не на том уровне, чтобы рассуждать о том, чей ответ более корректен. Лучше задавайте конкретные вопросы, я ведь всем отвечаю.

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

Компилятор решает задачу (пере-)компиляции и линковки исходного кода в исполняемый файл. Время работы всех известных мне компиляторов существенно зависит от организации исходного кода по файлам. Та самая «грамотная архитектура», священный грааль любого проекта. Метрика сложности зависимостей между файлами (между модулями) — я предполагаю, и пока не доказано обратное — как раз цикломатическая сложность ографа зависимостей модулей.

Почему не просто {1, 2, 3, …}?

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

Ну то есть ты согласен, что скинул (пусть и чужой) говнокод? 😁

В случае ЯП (да и не только их) на рынке почти всё решается сетевым эффектом, то есть, на языке все пишут потому, что все пишут на этом языке.

Здесь неистово плюсую. Кстати, ты есть в клубе? Я там как раз завёл тему насчёт сетевых эффектов в человеческом обществе

В какой-то момент я выгораю и в проекте всё становится настолько плохо, что я больше уже не могу и не хочу ничего делать.

В таком случае надо кидать (возможно, временно) этот проект и переходить к новому. Если ты один не тянешь, а больше помочь некому

Например, с технической стороны для ЯП обязательно быть простым. С маркетинговой стороны для ЯП обязательно быть как можно более сложным — тогда можно будет больше рассказать про фичи, которые в нем есть. Кстати, именно так был создан PL/I — я только не в курсе, в какой момент и почему он умер. В этом плане питон будет посложнее C++, и не зря за питон больше платят, ведь кол-во ad-hoc решений, которые нужно знать в питоне для разработки машинного обучения, будет поболее, чем в C++.

Питон взлетел благодаря формуле easy to learn, hard to master. C++ — это hard to learn, impossible to not shoot your own leg. But zero-cost, if done right

Просто у тебя гений - это тот, кто может предсказать развитие индустрии на 30 лет вперёд, плюс все эти годы у него есть возможность полностью контролировать развитие своего проекта. У меня требования не такие суровые.

Гений — это любой человек, который в состоянии сделать что-то оригинальное. Или как говорил мой учитель математики: «каждый человек — чудо».

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

Просто у тебя гений - это тот, кто может предсказать развитие индустрии на 30 лет вперёд, плюс все эти годы у него есть возможность полностью контролировать развитие своего проекта

Ну давай уже, скажи это прямо: тот, кто сможет продать проект корпорации. И мы закончим на том, что говорим про одно и то же.

Модули и односторонние зависимости между ними - это орграф, а та чухня, которую ты предложил - это не орграф

Там графы, тут графы — значит, они про одно и то же. Ок. Только не удивляйся, что тебя не понимают люди.

Там графы, тут графы — значит, они про одно и то же. Ок.

Так и работает математика

Только не удивляйся, что тебя не понимают люд

Давно уже перестал удивляться. Но я стараюсь

Здесь неистово плюсую. Кстати, ты есть в клубе? Я там как раз завёл тему насчёт сетевых эффектов в человеческом обществе

Клуб же мертв был до того, как я вернулся на LOR.

https://club.crypts.me/

Сохрани эту ссылку, сообщение скорее всего удалят с -2. Или -25 и баном, смотря на что способен макском.

Ты же фактически просил code review, разве нет?

Нет. Обсуждался вопрос, может ли хороший код иметь функции 300 строк. Если не 300, то 200 или 100. Один пример, когда такой код имеет право на жизнь, я привёл (протокол с case). Другой пример оказался неудачным.

Можно продолжать подбирать примеры, а можно воспользоваться какой-нибудь теорией. Цикломатическая сложность такую теорию частично даёт. Частично, потому что в случае, когда мы избавились от циклов и ветвлений, а код всё равно занимает много строк, то её уже нельзя использовать.

Вопроса тут никакого нет, constexpr для этого и создавались. Уж констнатные массивы заполнять они должны справиться.

Это только практика покажет. Мне проверять лень, поэтому поверю на слово. Не я же к этому несчастному массиву придрался.

Компилятор решает задачу (пере-)компиляции и линковки исходного кода в исполняемый файл.

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

Одно дело - время компиляции, другое - время перекомпиляции

Это правда. Это типа две чаши весов 🙂

Конечно, компиляция будет быстрее, если мы разделим исполнимые файлы. Перекомпиляция может стать медленнее. Как мы можем выиграть по времени, если и компилятору надо больше текста обработать, и линковщику больше объектных модулей собрать?

Лично мне, как разработчику, время перекомпиляции важнее. Потому что компиляция всей кодовой базы делается 1 раз, пускай даже она занимает 2-3 часа (сколько там хром собирается в генте?), но при разработке кода мне хотелось бы пересобирать проект с минимальными изменениями как можно быстрее.

Надеюсь, я достаточно ясно говорю в этот раз? А то меня тут уже начали упрекать

Ну то есть ты согласен, что скинул (пусть и чужой) говнокод?

Конечно, нет. Нормальный код. Можно сделать красивее? Можно. Но это не значит, что код плохой. Я, например, знал одну девушку-программиста, которая писала идеально красивый код. Только он либо не работал, либо делал не то, что было нужно заказчику. Краткость - это только один из параметров и он не самый главный.

Если бы мне надо было алгоритм Deflate перевести на другой язык программирования, то я бы взял этот пример, а не альтернативу, которую мне предложили, хотя там и кратко.

Цикломатическая сложность такую теорию частично даёт. Частично, потому что в случае, когда мы избавились от циклов и ветвлений, а код всё равно занимает много строк, то её уже нельзя использовать.

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

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

Конечно, нет. Нормальный код. Можно сделать красивее? Можно. Но это не значит, что код плохой.

Код не плохой, поскольку (наверное?) работает. Но уродливый, поскольку автор явно недостаточно знает язык. Либо боится использовать современные страндарты. Это уже его дело, а моё дело — написать ревью, если уж мне скинули чей-то гитхаб и попросили покомментировать.

Уродливый код = говнокод по определению.

Напоминаю, что красота — в глазах смотрящего (с)

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

Причём тут вообще пол программиста? Давай может не будем уходить в сексизм?

Краткость - это только один из параметров и он не самый главный.

Краткость — сестра таланта (с) Чехов

Эту реализацию какой-то маньяк-перфекционист делал, в хорошем смысле слова. Читается тяжеловато из-за обилия ifdef-ов, inline-ов, функций в одну строчку и прочих ухищрений. Но, вероятно, оптимизировано идеально.

Позвольте представиться: маньяк-перфекционист, который пишет идеально оптимизированный код, который, по возможности, легко читается. Хотя, конечно, легкость чтения напрямую зависит от опыта читающего.

компиляции… перекомпиляции…

Обнаружил смешной момент. Хотел понять не путаюсь ли я в терминах и что из этого Build, а что Build All. В википедии не обнаружил, там только про динамическую перекомпиляцию.

Вроде бы я уже натыкался на эту путаницу несколько лет назад. Но опять интуитивно посчитал, что перекомпиляция - это Build All, а компиляция - Build.

Причём тут вообще пол программиста?

Просто конкретный программист был девушкой. Как мне надо было написать? «Мой знакомый программист писала код». Как-то не по-русски будет.

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

Причём тут вообще пол программиста?

Просто конкретный программист был девушкой. Как мне надо было написать? «Мой знакомый программист писала код». Как-то не по-русски будет.

Окей. В таком случае, мне это видится как два подхода к одному и тому же. Если продолжить твою линию рассуждений, то неопытные мужчины пишут скорее рабочий код, чем красивый; а неопытные женщины пишут скорее красивый код, чем рабочий.

Однако, и тем и другим старшие товарищи (кстати, унисекс термин) должны надавать по шапке, научив мужчин писать читаемо, а женщин — логически правильно. И тогда будет мир, дружба, жвачка.

Ну давай уже, скажи это прямо: тот, кто сможет продать проект корпорации.

Не могу. Для меня создатели Zig, Nim и даже Nemerle - тоже гении. А продать проект пока не смогли. Разработчики Nemerle прямо перед тем как проект загнулся, радостно сообщили, что привлекли внимание JetBrains. После этого про этот язык я уже ничего не слышал.

Кстати, Kotlin возник как раз тогда, когда загнулся Nemerle. Но у меня нет каких-то данных, связано ли это.

Нет. Обсуждался вопрос, может ли хороший код иметь функции 300 строк. Если не 300, то 200 или 100. Один пример, когда такой код имеет право на жизнь, я привёл (протокол с case). Другой пример оказался неудачным.
Можно продолжать подбирать примеры, а можно воспользоваться какой-нибудь теорией. Цикломатическая сложность такую теорию частично даёт. Частично, потому что в случае, когда мы избавились от циклов и ветвлений, а код всё равно занимает много строк, то её уже нельзя использовать

Вся индустрия не может решить проблему, которую ты описываешь. Точнее, думает, что может, но на самом деле не может. Придумываются методы программирования, метрики оценки производительности, оценка читаемости по числу строк, заглавных букв, длине идентификаторов, но всё это не работает.

Дело в том, что задачи программирования зачастую заключаются в формализации, описании строгим языком того, что изначально описано как «сделать чтобы было зашибись». По этой причине каждое решение хотя бы в чем-то, но принципиально не похоже на предыдущее. Конечно, есть отдельные конвееры, которые клепают абсолютно одинаковые сайты, но обычно в итоге кто-то пишет генератор таких сайтов, а Вихан с Арджуном ищут себе новые ниши. Потому для каждого такого нового подхода нужны новые правила, новые метрики. То, что работало для прошлого проекта, не сработает для этого. То, что работало в начале, когда была активная разработка новых фич, не сработает в период продолжительной поддержки с малым числом новых фич, большим числом багфиксов и тестов.

Именно потому меня умиляют рассказы про «ваши проблемы от того, что у вас 300 строк в функции». 100% где-то на земном шарике так и решили: «у нас код говно, почему? — Дык ясно почему, 300 строк в функции» — хорошо, переписали функцию... Код все равно говно... «почему? — Дык ясно почему — у вас макросы с маленькой буквы» — хорошо, переписали... но код все равно остался говном. Как в той басне «вы друзья как ни садитесь, а в музыканты не годитесь». Я лично наблюдал такие пересаживания, когда начальство требует немедленно решить проблему, после чего команда меняет шило на мыло, а проблема не уходит.

Навык нахождения существенных факторов в чудовищном дефиците на рынке, но при этом ХЗ кому и как его вообще продавать, учитывая тот факт, что 95% заказчиков в IT — это спекулянто-барыго-банкиры, их основная работа заключается в том, чтобы запутывать людей, а не разъяснять, им обычно нужно либо решение плана «написать и выкинуть/продать», либо «мы купили кучу — твоя очередь в нее срать». Из-за этого также возникает второй феномен: почти полное отсутствие отсутствие людей с навыком проектирования и реализации, ориентированной на длительную разработку и поддержку. Навык поиска существенных факторов могу бы скомпенсировать эту проблему и помочь адаптироваться под новые условия, но увы, нету ни того, ни другого.

Разработчики Nemerle прямо перед тем как проект загнулся, радостно сообщили, что привлекли внимание JetBrains.

Если я правильно помню, то Nemerle создали два аспиранта из Польши, которые делали его в рамках работ по своим диссертациям. И бросили свой язык когда достигли своих научных целей. К тому времени Nemerle уже активно поддерживала группа товарищей с RSDN, которые и подхватили проект после того, как поляки Nemerle забросили.

Через какое-то время двое (а может быть и трое) из RSDN-еров, которые пилили Nemerle наиболее активно, были взяты на работу в JetBrains.

Но брали их туда не для того, чтобы Nemerle пилить, а чтобы переиспользовать их опыт для разработки технологий, нужных для JetBrains.

Но в JetBrains у товарищей что-то не пошло и со временем они оттуда ушли.

Все это дело можно попробовать поискать на https://rsdn.org/forum/nemerle Вроде бы там главный невменяемый по Nemerle, VladD2, всю эту историю со своей колокольни описывал.

Кстати, Kotlin возник как раз тогда, когда загнулся Nemerle. Но у меня нет каких-то данных, связано ли это.

Наверняка не связано вообще никак. Хотя бы потому, что Nemerle был изначально заточен под .NET, а Kotlin создавался именно под JVM.

Причём тут вообще пол программиста? Давай может не будем уходить в сексизм?

А тебя не смущает тот факт, что примерно 95% программистов — самцы?

Все это дело можно попробовать поискать на https://rsdn.org/forum/nemerle Вроде бы там главный невменяемый по Nemerle, VladD2, всю эту историю со своей колокольни описывал.

Вот здесь, например: https://rsdn.org/forum/nemerle/6408752.1

https://rsdn.org/forum/nemerle/6408752.1

Но все же я благодарен Джет Брэйнсу за то, что они дали нам это время и мы смогли не только произвести все исследования, но и написать 90% кода. Был бы лучше если они дали нам написать все 100% и распариться, но и на том огромное списибо

Как говорится «первые 90% кода пишутся 90% времени. Оставшиеся 10% кода пишутся еще 90% времени».

А тебя не смущает тот факт, что примерно 95% программистов — самцы?

Может поэтому тогда вокруг столько «зато работающего» говнокода? 😉

Ничего вы не понимаете в «лапше» и «нарезке». Бывает «лапша» в сурсах и не поддающаяся нарубке

Ты недооцениваешь мотивированности говокодеров.

Говнокодером тысячного уровня оно уже было создано, остальным приходится только повторять.

byko3y: Нетранзитивность константности и воображаемая сложность заставили. К слову, я дергаю мутабельная операцию ДРУГОГО объекта. Если константность объекта не приводит к константности объектов, на которые он ссылается, то что мне помешает из константного метода вызвать неконстантный метод другого объекта? Только честное слово.

byko3y: Нетранзитивность константности

eao197: Это объективная реальность.

Вынужден не согласиться с eao197.
«Нетранзитивность константности», то бишь невозможность в C++ явно специфицировать на уровне типов константность/мутабельность всех вложенных данных — это никакая не объективная реальность, а т.н. интерсубъективная реальность — то бишь, следствие архитектуры языка (заложенной г-ном Страуструпом), а также архитектуры STL и др.
В конечном счёте, как неоднократно было повторено в этом треде, ЯП - это просто (сделанный человеком) инструмент.

никакая не объективная реальность

Это именно объективная реальность, просто нужно научиться этим пользоваться.

В конечном счёте, как неоднократно было повторено в этом треде, ЯП - это просто (сделанный человеком) инструмент.

Есть! Ну наконец-то такая, казалось бы, простая истина была кем то озвучена.

никакая не объективная реальность

Это именно объективная реальность, просто нужно научиться этим пользоваться.

Методически, чтобы тебе возразить, я должен построить содержательный пример, показывающий убогость или даже несостоятельность возможностей C++ в контексте работы с константными/мутабельными данными.

С наскоку я его состряпать не могу, но задачка интересная, спасибо.

это никакая не объективная реальность

Ну Ok.

а т.н. интерсубъективная реальность

Проссыте, столь высоким материям не обучен.

Желающим еще порассуждать на тему const в C++ и гарантий, которые const, по их ощущениям, должен был бы предоставить, предлагаю покурить вот такой пример:

#include <new>

struct demo {
    const int a_;

    demo(int a) : a_{a} {}
};

void hoop(demo & d) {
    new(&d) demo{2};
}

int main() {
    demo d{1};
    hoop(d);
    return std::launder(&d)->a_;
}

Можно сделать ставки на то, какое значение main возвратит: 1 или 2.

В C++20, если я ничего не путаю, даже std::launder уже не нужен.

предлагаю покурить вот такой пример:

Гхм. Конкретно здесь всё очень плохо, лучше так не делать.

Я и не говорил, что это хорошо.

Но это есть. И такие вещи нужно принимать во внимание когда заходит речь о const в C++.

По твоей ссылке у меня

Application Error

ReferenceError: twttr is not defined
    at https://wandbox.org/build/_shared/chunk-HWTQ5KW5.js:104:29713
    at Gf (https://wandbox.org/build/_shared/chunk-2LKANNDY.js:9:6560)
    at L.unstable_runWithPriority (https://wandbox.org/build/_shared/chunk-2LKANNDY.js:1:4026)
    at rn (https://wandbox.org/build/_shared/chunk-2LKANNDY.js:5:38448)
    at Xe (https://wandbox.org/build/_shared/chunk-2LKANNDY.js:9:6029)
    at yi (https://wandbox.org/build/_shared/chunk-2LKANNDY.js:7:10750)
    at https://wandbox.org/build/_shared/chunk-2LKANNDY.js:5:38670
    at L.unstable_runWithPriority (https://wandbox.org/build/_shared/chunk-2LKANNDY.js:1:4026)
    at rn (https://wandbox.org/build/_shared/chunk-2LKANNDY.js:5:38448)
    at Cs (https://wandbox.org/build/_shared/chunk-2LKANNDY.js:5:38616)

Суровые крестовики ломают сэндбоксы на джаваскрипте своим кодом с UB 😁

Я привел исходный код.

Его можно запихнуть в любой другой online-компилятор или же попробовать своим собственным компилятором с поддержкой C++17.

За корректность работы wandbox не отвечаю.

Если есть что сказать по теме константности C++17, то пожалуйста. Остальное неконструктивно.

Вот примерно об этом я все время пытаюсь сказать. Любимое занятие программистов на крестах - обсуждение, что получится, если сделать так, как делать не надо.
Обычно они приходят к выводу «кресты - говно, потому что если сделать как не надо, то получится ХЗ что».