юнионы в C++

в Google работают люди со схожим взглядом на const как у тебя

Тот факт, что гугл единолично принимает решения по поводу развития C++, играл весьма позитивную роль до сих пор. Примерно как годные инициативы Microsoft, которые не проталкивались в стандарт просто потому, что MS была монополистом и могла тупо реализовывать те фичи, которые хотела.

Но на самом деле все-таки взгляд у них не как у меня, поскольку я вообще считаю const пагубной практикой.

У меня в принципе в телеге есть пункт «C++ слишком сложен», и вот вы к нему иллюстрацию создаёте прямо сейчас. Спасибо, ребят!

Абсурд в том, что если выкинуть C++ с концами и написать новый язык, очень похожий на C++, но без наследия, то на это потратится, грубо говоря, $100 млн, и в последующие 10-20 лет это сэкономит десятки миллиардов долларов и отправит тысячи программистов искать новую работу, потому что их труд по борьбе против компьютера окажется невостребован. Но нынешняя экономическая модель направлена на максимизацию бессмысленного труда, потому C++ даже выгоден. И поддержка 50-летних систем на коболе тоже выгодна, потому что безумно расточительна.

А точно при разработке Go были цели от начальства? Если мне не изменяет склероз, тут как раз инициатива шла снизу и на начальном этапе Go был подпольным проектом

Тут плюсую. Идее языка Go было лет 15-20 на момент начала его создания, а у гугла вообще очень много самых разных проектов с нижних уровней идёт. Но в какой-то момент абсолютно точно возникал реакция начальства «ух ты, а нам это пригодится. Дайте ему еще людей в команду»,

В том, что при столкновении пониманий (моделей реальности) первой естественной психологической реакцией является Отрицание

Хм-м-, неужели у меня поломанное восприятие? Моя первая реакция — это игнорирование. То есть, если я что-то не игнорирую, то я его уже не отрицаю прямо.

А Си обрастает инструментарием и методологиями, дающими работоспособные продукты

К сожалению, сколько не увешивай хромую кобылу костылями — она не сможет бегать так же быстро, как здоровый скакун. Это особо важно в программировании в том плане, что ключевой аспект работы программиста — это снижение ментальной сложности восприятия программы. Чем ниже ментальная сложность, тем больше можно написать/отладить за тот же промежуток времени. И всё упирается в то, что на Си можно написать такую же программу с близкими гарантиями надежности, но за время в 5 раз больше, чем на Go.

Какова должна быть сигнатура функции?

Тут вам должно быть виднее, это же ваш код.

Традиционный подход такой: когда вам нужна get_second в первый раз вы пишите ее максимально простой, именно такой какой она должна быть здесь и сейчас.

Когда вам get_second нужна во второй раз, то вы смотрите чем ситуации применения get_second отличаются.

И либо делаете какую-то универсальную реализацию, например, в виде шаблона:

template<typename Container>
[[nodiscard]] auto get_second(const Container & from) {...}

Либо же оставляете несколько различных версий get_second, каждая из которых оптимально подходит под свой сценарий.

Вся стандартная библиотека крестов слепена из такой копипасты

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

Во-вторых, проблема с необходимостью делать перегрузки методов для не-const, const, а так же для rvalue references случаев в C++ известна. В C++23 даже некое решение для завозят в виде предложения deducing this.

У меня есть ощущение, что авторы стандартной либы тяготеют к такому подходу, однако, как мы все понимаем, он далеко не самый эффективный.

Отучаемся говорить за всех.

И очень долго время под соусом const существовало три независимых вещи:

Во-первых, странная классификация, в очередной раз демонстрирующая что у вас в башке говно плещется. Первый случай из вашей классификации в C++ никогда const-ом не был.

Во-вторых, в C++ одни и те же вещи могут иметь разный смысл. Скажем >>. Или ключевое слово void в разных контекстах означает разное. Срать простынями бреда на LOR-е вместо того, чтобы понять, что «здесь сейчас так и никак иначе», – ну это больше об уровне вашего интеллектуального развития говорит, чем о проблемах языка.

Вот тебе сюрприз: когда я делаю vector[23] = std::string(«asd») — я тоже не меняю объект vector, он может быть константной ссылкой.

Не может. vector<T> – это вариация на тему T[]. Соответственно, когда у вас есть const T a[40], то операция a[23]=0 является попыткой поменять a.

Однако, если у вас T – это нечто вроде:

struct T {
  std::string * str_;
};

то вы можете написать a[23].str_->assign("abc"), потому что в таком случае a не меняется, в нем как были исходные значения, так они и остались.

И если вам не понятно почему, то повторите тему указателей. Например то, что у вас может быть константный указать (T * const) на неконстантный объект.

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

Всем.

Отучаемся говорить за всех.

Потому что const Type и Type станут взаимозаменяемыми.

Лично мне это нафиг не нужно. Как раз я ценю C++, в том числе и за то, что в нем const T и T в определенных случаях не взаимозаменяемы.

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

Вы у себя в коде используете

#define vl volatile

и вручную написанные функции по 350 строк длиной.

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

И вот криворукий говнокодер начинает рассказывать о том, что он что-то кому-то говорил про полезность const.

Какова ценность мнения криворучки по поводу фичи, которую он не освоил в языке, который он толком и не знает?

Вопрос риторический.

Задумался. Пришел к выводу — const не нужен.

Нет проблем. Вам не нужен, не используйте.

Мне нужен, я использую, время от времени компилятор бьет мне по рукам и предотвращает ошибки.

Если вы не хотите иметь такую помощь от компилятора, то не используйте const.

Остается, однако, вопрос, зачем об этом срать простынями бреда на LOR-е. Но в области психиатрии я не копенгаген.

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

Мой вам совет: если у вас в программе что-то происходит магическим образом, то смените профессию.

Опять-таки, разрабы стандартной либы в ряде случаев просто ничего не смогли с этим придумать, в ряде случаев начиная с C++20 в стандартной либе у методов наконец появились constexpr модификаторы, которые сами разбираются, вычисляемы ли они в compile-time или нет, а остальные случаи «не нужны».

Если вспомнить тот простой факт, что стандарт пишут обычные люди, которые и ошибаются, и не имеют безграничных ресурсов, то тогда можно прийти к выводу, что далеко не все в C++ном стандарте доводят до ума сразу. Что-то приходится вносить по результатам опыта и, местами, «когда дойдут руки».

Я предыдущим сообщением уже частично ответил, повторюсь: std::list<const char*>.

Нет, не ответили.

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

По сути, Go — это Java, сделанная по-человечески.

Да-да, про ваше ниасиляторство ООП я уже в курсе.

«это другое». Для begin есть две перегрузки: non-const и const. А cbegin - это для того, чтобы вызывать const перегрузку begin, без приведения (каста) объекта к ссылке на const-qualified тип.

Всего одну? Я знаю ещё парочку.

Остальное все обходится.

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

К сожалению, сколько не увешивай хромую кобылу костылями — она не сможет бегать так же быстро, как здоровый скакун.

Вот только здоровых скакунов нет. Вообще.

Ибо, если бы они были бы здоровы, давно бы обскакали. Но это не так.

У каждого проблемы. Вот эти проблемы и надо латать.

И всё упирается в то, что на Си можно написать такую же программу с близкими гарантиями надежности, но за время в 5 раз больше, чем на Go.

И по этому идёт падение популярности Go?

Или потому что его чуть-чуть усложнили, добавив необходимое, и желающих его изучить сразу стало сразу меньше?

Написали Rust. И как, помогло?

Основная проблема крестов в том, что все программисты почему-то считают себя умными. А основной объем кода пишут как раз именно те, которым пока рановато. Но им кажется, что они готовы и даже обязаны использовать все богатство фич и выразительных средств, о которых они только что узнали из стрима очередного бородатого юноши.
Так и возникает ситуация, когда не очень умный человек занят интеллектуальным трудом на пределе (и даже далеко за пределами) собственной компетентности. А потом ползает по интернету с оторванными руками и ногами и вопит о том, как ему больно и небезопасно.

Хорошо, для провоцирования флейма,

Нет, просто не подумал. Я не задумываюсь над теми проблемами, которые передо мной не стоят, в т.ч. и над проблемой шрифтов VS Code. Касаемо данного обсуждения, здесь шрифты в VSCode - не тема, а дальняя побочная ветка, нефиг ей уделять внимание. Ну ясно, буду знать, что и VSCode хромает, просто мне не попалась эта ситуация, т.к. у меня FullHD на большом мониторе.

И по этому идёт падение популярности Go?

Или потому что его чуть-чуть усложнили, добавив необходимое, и желающих его изучить сразу стало сразу меньше?

Можно поподробнее с этого места?

• как замеряно снижение популярности?
• что добавили (дженерики собирались добавить вроде, не слежу за темой, их добавили или что?)

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

какая еще идеология «STL auto», auto - это вывод типа переменной по выражению. просто синт. сахар такой, чтобы явно тип не писать.

и с какой стати оно должно стать указателем на неизменяемое значение???

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

выучи уже с++, потом спорь.

(в ответ на «Ява не нужна?»)

нет конечно.

(через пару коментов)

оба нужны,

таки я не понял, нужна ява или нет?

Это очень плохо налазит. Вы не хотите проверять что Ваш cache up-to-date на каждом доступе через итератор, и уж тем более не хотите заставлять его синхронизироваться на каждом доступе (что потенциально может быть очень дорого, несопоставимо дороже чем собственно доступ). Вы хотите это делать в контролируемые моменты времени. Какие именно - зависит от конкретной задачи.

Согласен с вами, мой пример налазит не очень. В таком случае надо найти другой кейс, где cbegin нужны другие кишки, нежели begin — и нельзя обойтись кастом одного другогому. Не зря же отцы STL оставили такую возможность?

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

Проверка валидности кэша — это м.б. проверка одного ptr на nullptr (если где-то произошла mutable операция — ставим ptr на этот чанк кэша в nullptr). Но я с вами согласен, что для дерева «вообще» даже такие приседания м.б. слишком затратны

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

Ты писал в комитет?

таки я не понял, нужна ява или нет?

да все когда нибудь пригодится… не выбрасывай ее пока.

Основная проблема крестов в том, что все программисты почему-то считают себя умными. А основной объем кода пишут как раз именно те, которым пока рановато. Но им кажется, что они готовы и даже обязаны использовать все богатство фич и выразительных средств, о которых они только что узнали из стрима очередного бородатого юноши. Так и возникает ситуация, когда не очень умный человек занят интеллектуальным трудом на пределе (и даже далеко за пределами) собственной компетентности. А потом ползает по интернету с оторванными руками и ногами и вопит о том, как ему больно и небезопасно.

Эффект Данинга-Крюгера. Но наличие этого эффекта никоим образом не означает, что сам язык хорош.

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

Ну просто ты написал, что якобы VSCode написан на плюсах, но это лишь часть правды.

А тех плюсистов, которые «умные», т.е. уже осили ремесло, всегда меньше, чем нужно.

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

Нет, я такого не писал. Я писал, что vscode опирается на технологии, написанные на плюсах.

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

Именно. Поэтому, кто готов к работе, а кто - нет, определяет рынок. И в этом плане нет никакой проблемы «готовности», ни в C++, ни в программистах на нем.

Спасибо!

И в этом плане нет никакой проблемы «готовности», ни в C++, ни в программистах на нем.

Однако, если сравнивать порог входа в C++ с порогом входа в какой-нибудь Go или Python, то для C++ он таки явно выше. И для того, чтобы разработчик смог писать нормального уровня код без присмотра старших товарищей нужно больше времени и сил.

Так что какая-то доля горькой правды в словах thesis все-таки есть.

Вот с Rust совершенно иная история, именно как ты говоришь: там по большей части крестовики собрались переписывать кресты на новый лад, тщательно повторяя многие недостатки крестов, в том числе повторяя монструозность.

Можно список недостатков, которые повторены в Расте?

Однако, если сравнивать порог входа в C++ с порогом входа в какой-нибудь Go или Python, то для C++ он таки явно выше. И для того, чтобы разработчик смог писать нормального уровня код без присмотра старших товарищей нужно больше времени и сил.

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

если где-то произошла mutable операция — ставим ptr на этот чанк кэша в nullptr

Вот. Вот оно. Если бы Вам удалось полностью избавиться от зависимости tree на tree_view (ie заставить tree_view правильно работать без active feedback от tree) горизонты для дальнейших улучшений были бы гораздо шире. Например можно иметь несколько tree_view на каждый tree, можно в каждом instance иметь свою стратегию синхронизации, можно partition underlying tree (позволю себе предположить что Вы параллельными вычислениями занимаетесь - там бы это возможно было очень полезно), etc.

ПыСы. Я было подумал что Вы что-то более сложное задумали. Например tree может вести log последних изменений в каком то виде, и view смотрит на этот log чтобы отдать наиболее актуальные данные без полного переиндексирования tree, etc.

Тем не менее, у них всех был какой-то фатальный недостаток и Rust с Go появились. Как и Dart, например. Или Kotlin.

И чем же Go лучше D, а Kotlin лучше C#? Это все примерно одно и тоже. В Rust хотя бы интересные идеи по управлению памятью есть.

родить идею нового языка, с пониманием того, зачем нужен именно такой

Основная ошибка создателей - попытка создания языка, который делает всё. Больше шансов имеют языки, которые решают определённую задачу, типа bash или PHP. Да даже какой-нибудь скрипт NSIS наверное изучило больше человек, чем универсальный язык D.

Есть же здравый смысл. Он велит задаваться вопросом «если я отстрелил себе все выступающие части тела, а при этом давным-давно, даже до с++11, существовал очень навороченный, шустрый и стабильный софт на крестах, то может проблема не в языке?»
И это очень, очень простой вопрос.

Основная ошибка создателей - попытка создания языка

Вот здесь нужна точка.
Новые языки не нужны уже очень, очень, ОЧЕНЬ много лет. Нужны реализации протоколов, парсеры форматов, мультимедия-либы, гуйцы, коннекторы БД, IPC и прочие ЖБИ для прикладухи.
Но как же хочется почесать ЧСВ и создать свой, новый язык «Хѣръ» на основе шумерского алфавита, написать книжек, начитать лекций, наснимать роликов, насосать грантов...

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

начнёт постепенно доходить, что жрать кактус необязательно

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

Ты же C++ не знаешь, откуда у тебя мнение о C++?

НУ ВОТ ЖЕ В ТРЕДЕ ВСЕ ОБЪЯСНИЛИ.
Теперь можно писать статью на хабре «кресты - говно», чтобы потом какие-нибудь дятлы ее регулярно таскали обратно на ЛОР.

Язык на основе кириллицы есть в 1С, входит в пятёрку в России по спросу на рынке труда. Но к теме всё это никак не относится.

Да, я знаю только очень старые плюсы, потому и тред. Но в общем-то на выходе из треда то же, что и на входе:

• на практике не полностью закрывает сишные дыры
• чрезмерно сложен

И чем же Go лучше D,

Гораздо проще. И гораздо, гораздо, гораздо стабильнее в своем развитии.

Kotlin лучше C#?

У Kotlin-а не было задачи быть лучше C#, т.к. он создавался для другой экосистемы. Kotlin оказался удобнее Java и проще Scala.

Ты же C++ не знаешь

Так ему buko3y напел.

я знаю только очень старые плюсы на практике не полностью закрывает сишные дыры

Не обманывайте себя. Если бы вы знали хотя бы старые плюсы, то и без треда знали бы, что «на практике не полностью закрывает сишные дыры». И не может закрывать в принципе.

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

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

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

у меня все.

Новые языки не нужны уже очень, очень, ОЧЕНЬ много лет.

Всё новое - нужно. Это, типа, аксиома. Так работает наука, заранее никогда не знаешь, что в итоге получится и куда это пригодится. ЯП - это Computer Science, так что.

Нужны реализации протоколов, парсеры форматов, мультимедия-либы, гуйцы, коннекторы БД, IPC и прочие ЖБИ для прикладухи.

Это тоже нужно. Старые [уже распространённые в области] языки ведь никто не отнимает, и всегда можно написать биндинги. Так ведь и делают, когда хотят использовать старую либу в новом-модном-молодёжном языке?

Но как же хочется почесать ЧСВ и создать свой, новый язык «Хѣръ» на основе шумерского алфавита

Зачем это? Я за латиницу, на выразительную мощь ЯП это не влияет. Комменты тоже на английском писать.

Не совсем ясно, что конкретно - «адъ, шок и трепет», и если это не ирония, а реальность, то зачем ты это делаешь. Ну разве только чтобы формы не терять.

Какое отношение строки-массивы имеют к дополнительным блокам памяти?

Сколько нужно дополнительных блоков, чтобы выделить std::shared_ptrstd::string ? Два-три.

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

2. Меньше 2 на мутабельную строку выделять не получится в принципе без дополнительных приседаний – со всеми оптимизациями.

И почему-то нам не хотелось написать свой стандарт, который бы нам помешал это сделать.

Интрузивные хэш-таблицы отношения к unordered_map не имеют. unordered_{map,set} вошли в стандарт такими по историческим причинам, и даже с этой оговоркой являются достаточно производительными. Интрузивные хэш-таблицы в Boost обладают специфичным интерфейсом, не подходящим для обобщенного использования.

Выполнив некорректную последовательность деструкторов RAII может выстрелить себе в ногу

Выполнив некорректную последовательность финализаторов, GC может выстрелить себе в ногу

Повреждение памяти намного, НАМНОГО опаснее, чем просто утекшие ресурсы.

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

Сейчас это тупо примитивный сахарок для расчета выравнивания структуры

Нет, это не сахарок для расчета выравнивания структуры

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

С вообще не для высокоуровневого программирования.

Он велит задаваться вопросом «если я отстрелил себе все выступающие части тела, а при этом давным-давно, даже до с++11, существовал очень навороченный, шустрый и стабильный софт на крестах, то может проблема не в языке?»

Элементарно! Создатели этого стабильного, быстрого и т.д. софта давно уже на все грабли наступили и запомнили. Не наступи они в свое время на грабли, не было бы никакого стабильного,… софта.