юнионы в C++

более высокоуровневый код, близкий к питонохаскелям

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

Но ты в любых улучшениях только один клей и видишь. Странно что filesystem оказался исключением.

Не один. Как минимум, еще потоки, регулярки и некоторые другие библиотеки из состава STL. filesystem привел ты, поэтому в качестве примера я использую его.

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

Нет, классы разграничивают доступ к своим полям и методам при помощи модификаторов доступа и потому не могут быть реализованы «на любой сишке». Как минимум поэтому классы не клей. Сишные структурки – клей.

Как минимум она позволяет перейти к монадической обработке ошибок вместо кодов возврата или исключений.

Исключения на порядок более высокоуровневы, чем optional и любой sum-тип. «монадическая обработка ошибок» это баззворд, не имеющий смысла.

Довольно значительные изменения для «чисто библиотечной фичи для удобства», не?

Нет, никаких изменений внесено не было, Boost.Optional существовал годами до std::optional. Был ли язык высокоуровневым? Для сравнения, до внесения потоков в С++ понятия потока в стандарте не существовало.

Как во всяких растах, эфшарпах и т.д

Не делает чести ни одному из них.

Можно конечно. А еще можно вообще на асме писать. Это тоже всего лишь менее эргономично, но ничего принципиально не меняет.

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

И именно поэтому С++98 косил под джаву. Аргументация у тебя конечно уровня бох.

Да, именно так. Только не 98, об этом я уже написал.

То что джаву срисовывали в том числе и с С++, это понятно. А вот в обратную сторону - это прямо что-то новенькое.

Это не односторонний процесс. Джаву слизали с тогда полностью убогих крестов. Джава взлетела, С++ попытался уйти в ту же сторону. Не вышло.

Нет. С++11 это начало перерождения крестов из убогой недоджавы/си с классами в действительно мощный язык.

Господа Siborgium, rupert, Crocodoom, AntonI, glebiao, eao197: спасибо! Вы реально сделали мой день ;) Аж целых 9 страниц глумления о школьном сочинении на тему «Почему папин дробовик опасная штука, сколько есть способов отстрелить им себе ногу, и почему мой водяной пистолетик самая крутая и полезная штука в хозяйстве?». Аплодирую стоя!

ПыСы. Попкорном закупился и требую продолжения банкета ;)

ПыПыСы: некоторые из цитат, с вашего позволения, уходят в мой «золотой фонд», жгите дальше (без намёка на сарказм) ;)

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

Не постесняюсь спросить: «а кто будет судьей, решающим что лучше, а что хуже?»

Неужели вы?

Тот самый, который зачем-то прячет ключевое слово volatile за двухбуквенным макросом vl? И который фигачит функции по 300+ строк?

Неужели это вы будете запрещать ковыряться мне в носу?

Судя по этому милому говнокоду букози сначала самостоятельно учился писать на вижуал бейсике. Бесконечные цепочки a->b->c->… что бы доковыряться до нужного поля оттуда.

С таким бэкграундом что можно от товарисча хотеть? Обнять и плакать.

На самом деле все очень грустно.

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

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

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

Все, что у человека есть объясняется с точки зрения эволюции. Начиная от строения скелета и заканчивая потреблением кислорода.

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

Представим себе, что кто-то начинает рассказывать насколько лучше устроены нижние конечности у шимпанзе, насколько удобнее было бы, если бы мы могли помогать себе ногами так же, как это делают шимпанзе. Вот у шимпанзе же почти что четыре руки, тогда как нам приходится обходиться двумя. А ноги нам сейчас почти что уже и не нужны, особенно программистам, которые по 8-10-12 часов в сутки сидят за компьютерами.

И т.д., и т.п.

Да еще и если бы этот человек отмахивался бы от попыток объяснить ему почему же наш вид сформировался именно так.

Суть же в том, что человеческий вид сейчас именно вот такой.

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

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

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

И т.д., и т.п.

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

Получилось вот так.

Можно писать бесконечные простыни о том, насколько в C++ все плохо по сравнению с другими языками программирования, как бы оно могло бы быть если бы. И какие же редиски те, кто не сделал 30 лет назад так, как это сейчас очевидно buko3y. Но конструктивным это будет лишь в случае, если кто-то задумал сделать еще один язык программирования и пытается учесть просчеты в других языках.

Но вот если нужно делать реальные проекты и язык C++ волею судьбы оказался одним из немногих ЯП, на которых эти проекты разумно, практично и эффективно делать, то бесполезно раздувать очередной флейм на тему того, как плохо в C++ со встроенными массивами и почему на ООП ничего хорошего сделать нельзя.

Только вот buko3y на пару с den73 занимаются как раз вот этим. Вместо того, чтобы потратить время и изучить таки инструмент. Ну или просто выбрать другой, который будет для них удобнее.

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

Хотя, на самом-то деле, оба несут откровенный бред. Иногда с налетом шизофрении.

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

Однако, he is learning (c)

Жир потёк с монитора. Можно в твоём хот релоаде удалить поле из объекта или добавить обязательный аргумент в функцию?

Можно в твоём хот релоаде удалить поле из объекта

Нет

Error: Edit and Continue does not support changes to data types; build required

или добавить обязательный аргумент в функцию

Да.

Была такая функция:

void test() {
	cout << "test1 executed\n";
}

сделал такую

void test(int a) {
	cout << "test2 executed, a = "<< a << "\n";
}

Из другого объектного файла вызвал, всё норм: https://imgur.com/a/WcUc5mh

Но всё же выдаёт предупреждение:

warning NEN2000 : Variable or function 'test' was removed. Undeleted and undetected references could still exist

Для начала — ты своими «диагнозами» оскорбляешь людей. Про шизофрению, идиотию и всё это вот — это уместно в кабинете психиатра. Но ЛОР не кабинет психиатра, а ты не врач, ведущий в этом кабинете приём. Да и вообще переход на личности вместо разговора по существу всегда выглядит жалко. Я мог бы этот комментарий просто снести по 5.2, но с поправкой на то, что ты своей простынёй явно хотел что-то сказать, ограничиваюсь предупреждением.

По сути же того, что ты хотел сказать…

идиотическим нежеланием воспринимать реальность такой, какая она есть

Вообще-то, история в целом и IT в частности двигается именно людьми с нежеланием (бывает, что и маниакальным) воспринимать реальность такой, какая она есть, а если точнее — считать эту реальность неизменной. И den73, кстати, пытается делать свои языки. Другое дело, что ему бы в таких случаях поменьше думать о «телегах против плюсов» и побольше — о том, чтобы выкатить что-то уже работающее. О недостатках плюсов индустрия уже давно в курсе, в том числе и те, кто на этих плюсах каждый день пишет. Я бы на месте den73 делал бы упор на то «почему вам стоит мигрировать с плюсов на мой диалект Оберона, а не на C# и не на Java».

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

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

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

Для начала — ты своими «диагнозами» оскорбляешь людей.

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

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

Вообще-то, история в целом и IT в частности двигается именно людьми с нежеланием (бывает, что и маниакальным) воспринимать реальность такой, какая она есть, а если точнее — считать эту реальность неизменной.

Рискну напроситься на бан, но тут приходится задать вопрос вам: а у вас с головой все нормально, противоречия в том, что пишете не видите?

Нет не вижу. Ну разве что мы можем по-разному трактовать слова «воспринимать реальность». Я говорю не о том, что человек чего-то не замечает, а о том, что он ищет пути эту реальность менять.

Для того, чтобы что-то поменять нужно a) понимать что есть сейчас, b) отдавать себе отчет о том, что именно не устраивает, c) иметь представление о том, что же хочется получить и d) понимать что и как нужно сделать, чтобы это самое получить.

Все это идет в прямое противоречие с «нежеланием воспринимать реальность такой, какая она есть». Тут как раз нужно настолько трезво оценивать эту самую реально, как доступно не только лишь всем.

Ну и собственно, сперва люди пишут слова не думая о том, какой смысл получается у написанного, а потом предъявляют претензии, когда указывается, что со стороны наблюдаются признаки шизофрении.

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

Про Страуструпа он, конечно, глупость сболтнул. Но при этом в соседнем комментарии высказался за нормальную систему модулей. И тут БАЦ — вспоминаем, что в C++20 эти самые модули добавляют…

Я на всякий случай напоминаю, что «нежеланием воспринимать реальность такой, какая она есть» — это из вас была цитата.

Вы всерьез решили пойти по пути den73, который выше пытался отнекиваться от того, что наговорил Siborgium? Ну, ok.jpg, расставим точки над ё.

buko3y вопит тут про кучу проблем C++, последнее, если не ошибаюсь, было про константы. Вместо того, чтобы попытаться разобраться как const работает в C++ он истерит про то, что const в C++ – это не const, а так, что-то непонятное.

Это и есть (один из) пример того, что buko3y не желает воспринимать реальность такой, какая она есть. Вместо он вопит «а пачиму не так, как я люблю?!!!»

Отсюда и происхождение моей фразы.

После чего появляетесь вы (причем непонятно в какой роли: модератора или участника спора) и заявляете:

Вообще-то, история в целом и IT в частности двигается именно людьми с нежеланием … воспринимать реальность такой, какая она есть

Что явно противоречит тому, что я наблюдаю вокруг себя, а именно: меняют эту самую реальность как раз те, которые смотрят на мир не сквозь розовые очки и прекрасно понимают что к чему и почему. Поэтому-то они и меняют, а не вопят на форуме «а пачиму не так как я люблю?!!!»

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

Ну и для примера. buko3y тут клепает портянки о том, как в C++ все плохо и как были просраны полимеры много лет назад потому, что не скопировали что-то откуда-то. А вот Sean Baxter берет и делает свой экспериментальный C++. В том числе и с фичами, об отсутствии которых buko3y тут причитает.

Вот вам и разница между теми кто принимает мир как он есть (Sean Baxter) и теми, кто не может этого сделать (buko3y).

После чего появляетесь вы (причем непонятно в какой роли: модератора или участника спора)

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

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

Тяжело быть непризнанным гением? (:

*item.b = std::string(«Bitch»);

Это не проблема const, а проблема shared_ptr, который в константном операторе «*» возвращает _не_ константную ссылку. Он по поведению пытается прикидываться сырым указателей. const shared_ptr<T> это T * const, а не const T *. Если такие фокусы не вытворять, то const нормально пробрасывается и блокирует попытки изменений, как в моём примере.

Ты ухватился за «читерский» класс и на его основе сделал вывод о ничтожности const.

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

Чтобы безупречно проверить выравнивания, нужно чтобы в языке не было каста типа указателя. Да, я согласен с тем, что инициатива интеерсная, но в сишечке нереализуемая, поскольку кто-то кастанет твой char * в int * — и привет.

Тебе действительно нужно объяснять, почему необходим control block для реализации strong- и weak- ссылок?

Да. В паскале строки-массивы почему-то без дополнительных блкоов памяти реализованы.

4.2, единственная «прокладка» там это _Rb_tree_node, которая необходима для хранения указателей на другие ноды вместе со значением. На значение она не ссылается, а хранит значение в качестве поля

Сорян, не помню наизусть реализацию STL. Но в unordered_map/unordered_set/unordered_multiset/unordered_multimap двойные указатели:

https://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc /api/a00903_source.html#l00178

Бездарный бред, никакого отношения к STL это не имеет и (если пояснение все же нужно) никем не используется

Да, речь шла про STLFilt, но общей проблемы криптоошибок оно не решает. Сорян, если я не угадал, про какой ты там свой инструмент вёл речь.

Сборщик мусора не решает никаких проблем, кроме проблемы циклических ссылок

Как это «никаких», если он позволяет не париться о высвобождении памяти, в том числе после исключений?

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

…прямо как деструктор

Если деструктор у тебя один на всё приложение, то да, «как деструктор». Но если деструкторов два, то может возникнуть ситуация, когда один деструктор дернул другой деструктор, а другой — обратно первый. Кто будет проверять, что деструктор вызвался ровно один раз и обязательно до высвобождения памяти? В стэковой машине на RAII это еще как-то с горем пополам можно полдучить что-то стабильное, а с глобальной памятью уже не получится, а в многопотоке и вовсе можно сойти с ума в процессе.

Да, я согласен с тем, что инициатива интеерсная, но в сишечке нереализуемая, поскольку кто-то кастанет твой char * в int * — и привет.

не проверял, но сто пудов что в

union {
  uint8 _byte;
  uint64 _word64;
}

тут юнион будет выравниваться по наихудшему варианту, то есть как uint64, размер юниона - 8 байт. и адрес полей и _byte и _word64 - одинаковый.

Можно писать бесконечные простыни о том, насколько в C++ все плохо по сравнению с другими языками программирования, как бы оно могло бы быть если бы. И какие же редиски те, кто не сделал 30 лет назад так, как это сейчас очевидно buko3y. Но конструктивным это будет лишь в случае, если кто-то задумал сделать еще один язык программирования и пытается учесть просчеты в других языках.
Но вот если нужно делать реальные проекты и язык C++ волею судьбы оказался одним из немногих ЯП, на которых эти проекты разумно, практично и эффективно делать, то бесполезно раздувать очередной флейм на тему того, как плохо в C++ со встроенными массивами и почему на ООП ничего хорошего сделать нельзя.
Только вот buko3y на пару с den73 занимаются как раз вот этим. Вместо того, чтобы потратить время и изучить таки инструмент. Ну или просто выбрать другой, который будет для них удобнее

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

К сожалению, аргумент «поди и изучи» не сработал 15 лет назад, не сработал бы и сейчас. Совсем другое дело — писать за денюжку крестовый проект в сишном стиле, при этом бурно обсуждая с целым лором по поводу того, как же все-таки его лучше было бы писать. Я бы с радостью вычитал готовые ответы в книжках, но в книжках ответов нет. И да, на ООП ничего хорошего сделать нельзя — именно потому C++11 стал таким «новым» языком. Или по поводу того же const — тема «использовать или нет» действительно очень спорная. потому что const в крестах слишком кривой, но и без него взаимодействовать с той же STL тяжко — приходится сидеть на двух стульях поочередно.

Можно считать, что я экономлю годы на изучение C++ для того, чтобы потом без тени смущения сказать «ага, я наконец понял, как с ним работать» и пойти изучать другие технологии и языки. а не засесть на крестах на десятилетия, высматривая и запоминая расположение каждой козявки, каждого крошечного костылика, и потом в 45 лет рассказывать «этот ваш C++37 с автоматической сборкой модулей — такая бездушная ерунда, нивелирующая все возможности по созданию билдскриптом на автотулзах полуавтоматически, с душой, чтобы каждый файлик имел собственные опции сборки, без которых проект не скомпилируется; сообщения об ошибках ваши в C++34 несерьезны совсем, по ним сразу видно, из-за чего ошибка, чуть ли не автоматически можно эти ошибки исправлять, вот в наше время ошибки компиляции были произведением искуства, каждое сообщение читаешь как повесть».

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

Вот я сколько общаюсь с крестовиками — я не вижу этого понимания. Да, есть чудовищные антипаттерны, патологичность которых очевидна уже всем, но есть менее очевидные антипаттерны, по которым еще и куча библиотек написана, и теперь когда ты пишешь на Qt, то ты ВЫНУЖДЕН писать плохо.

Я бы на месте @den73 делал бы упор на то «почему вам стоит мигрировать с плюсов на мой диалект Оберона, а не на C# и не на Java»

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

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

Тот же buko3y может делиться своим мнением и называть Страуструпа манагером-продажником, хотя Страуструп, насколько мне известно, ни менеджером, ни продажником не был

Извини, но Страуструп сам признается, что понимает, как и почему происходила история с C++, а значит понимает, что пользуется случаем в корыстных целях. Да, он не торгует носками, потому что у него не подвешен язык, но это не мешает ему торговать чем угодно другим. Может быть, с менеджером я переборщил, да, посыпаю голову пеплом. Но продажник. Такие еще носятся с вечными двигателями и лекарствами от рака.

А вот кто помнит автора Rust? Какие там он книжки пишет, на каких лекциях выступает, каким профессором работает? Нужно понимать, что «популяризатор» = «продажник», популяризатор обычно имеет косвенное отношение к популяризуемому предмету, в то время, как про настоящих авторов никто ничего не знает. Как бы, быть популяризатором-продажником — это не плохо и не хорошо, но я вношу поправочные коэффициенты на это искажение восприятия, напоминая, что Страуструп — это мелкая сошка, которая имела сомнительную роль на заре становления C++, и еще более второстепенную по мере становления языка.

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

buko3y вопит тут про кучу проблем C++, последнее, если не ошибаюсь, было про константы. Вместо того, чтобы попытаться разобраться как const работает в C++ он истерит про то, что const в C++ – это не const, а так, что-то непонятное.
Это и есть (один из) пример того, что buko3y не желает воспринимать реальность такой, какая она есть. Вместо он вопит «а пачиму не так, как я люблю?!!!»

Есть языки, в которых константы являются константами. Костантность не выкастовывают, на константный объект не держат неконстантную ссылку. Есть языки, в которых изменяемые и неизменяемые объекты являются одним и тем же (персистентные структуры данных). Но проблема const в крестах в том, что она вроде как константа, но вроде как и не константа, но называется константа. То есть, самолет из соломы, но выглядит как самолет — значит, самолет у нас реализован. А если такой самолет к тому же у нас купили, то это точно самолёт. И такая ситуация просматривается по всем фичам ранних крестов. Так же пришел к успеху Гвидо — это очень даже рабочий способ. Но с позиции технаря-авиаконструктора ситуация в индустрии выглядит как полный треш, и тот факт, что Страуструп хорошо заработал на продаже соломенных самолетов, не является для технаря достаточным оправданием.

Ну и для примера. buko3y тут клепает портянки о том, как в C++ все плохо и как были просраны полимеры много лет назад потому, что не скопировали что-то откуда-то. А вот Sean Baxter берет и делает свой экспериментальный C++. В том числе и с фичами, об отсутствии которых buko3y тут причитает

Допустим, я хочу сделать что-то подобное тому, что сделать Шон Бакстер. Откуда я возьму идеи? Где я возьму 10-20 лет опыта страдания на крестах? Для этого и нужны подобные треды.

Тяжело быть непризнанным гением?

Пока держусь.

Это не проблема const, а проблема shared_ptr, который в константном операторе «*» возвращает _не_ константную ссылку. Он по поведению пытается прикидываться сырым указателей. const shared_ptr<T> это T * const, а не const T *. Если такие фокусы не вытворять, то const нормально пробрасывается и блокирует попытки изменений, как в моём примере

Авторы STL постарались максимально обтекать вокруг кривизны const. На самом деле есть кучу потенциальных задач, где понадобится менять поля объекта с «константным» значением — об этом я писал изначально. Авторы STL до последнего пытались делать вид, что проблемы не существует, но shared_ptr оказался слишком лакомым кусочком, чтобы избегать его реализации, а на него const не налазит, криво получается хоть так, хоть эдак. Он не является исключением, это самый обычный контейнер, довольно примитивный, но он прекрасно демонстрирует убогость крестового const, который тут работает, а здесь уже не работает.

Напоминаю, что мой главный аргумент был в том, что const работает «через раз». Если довести это до абсурда, то можно сказать «в языкнейме ссылки безопасные, они иногда дают гарантии корректной работы с памятью, а иногда — не дают. Но если постараться, то можно сделать так, что чаще будут давать гарантии, чем не давать» — это что за такие «гарантии»? Если по итогу ошибки логики с недопустимым изменением переменной я все равно буду отслеживать руками, то в чем ценность этой гарантии? Это коммент. Кому-то полезный, кому-то удобный. Но можно писать совсем без него, пользуясь другими комментами, другими псевдонимами типов. А можно и с ним. Но мне нравится без него. STL написан с const — при использовании STL придется использовать const. Но если я не пишу на STL, то я могу обойтись без const.

Вот в D пришла авторам блажь перенести битовые поля на уровень библиотеки. Кому-то стало от этого хорошо?

А кому плохо?

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

Ну как прошлый, Го спёрли с Активного Оберона, добавили туда фигурные скобки, ещё кое-что и финансы гугла. Взлетел пинком как миленький, в самом что ни на есть XXI веке. А так я считаю не вполне корректным в ответ на жалобу на оскорбления и диагнозы, что товарищ приходит, начинает увещевать оскорбляющего, а меня начинает учить, что именно мне делать. Спасибо, я сам разберусь, что мне делать, а от товарища я ожидаю защиты от прямых оскорблений. Если уж до этого нет сил дотянуть, то можно хотя бы разделить увещевания агрессора и поучения жертвы и не ставить их в одном сообщении.

чтобы выкатить что-то уже работающее

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

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

Вот именно, но когда начинается обсуждения о недостатках языков, то внезапно всплывают кадры с позицией «как ты смеешь критиковать мой любимый инструмент? Смирись, и пользуйся как велено творцом!». Почему я должен смириться? Я в вашей церкви не состою так-то.

Их можно понять, им обидно, и даже простить. Пусть ступают себе с миром.

Ну как прошлый, го спёрли с Активного Оберона, добавили туда фигурные скобки, ещё кое-что и финансы гугла

Не вижу у них ничего общего. CSP и зеленые потоки сами по себе были довольно старыми инструментами, зато вижу наследие Newsqueak/Alef/Limbo (в хронологическом порядке), переписанное на синтаксис Си. Конечно, я слабо знаком с Оберном, может быть ты подскажешь.

Ну как прошлый, Го спёрли с Активного Оберона,

таки Go есть наследник Limbo.

https://en.wikipedia.org/wiki/Limbo_(programming_language)

лимбо появился раньше активного оберона

таки Go есть наследник Активного Оберона и ещё аж двух других Оберонов:

https://en.wikipedia.org/wiki/Go_(programming_language)

«C, Oberon-2, Limbo, Active Oberon, communicating sequential processes, Pascal, Oberon, Smalltalk, Newsqueak, Modula-2, Alef, APL, BCPL, Modula, occam»

но позже просто Оберона, от которого Активный отличается await-ом и мониторами - не очень сильно. В контексте вопроса про технологии прошлого века в общем-то не суть важно, от чего голанг взял больше - от лимбо или от АО.

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

ну в общем-то правдой является то, что и Лимбо повлиял, и Активный Оберон. А ещё проект Оберон повлиял на Plan9 (пруф http://doc.cat-v.org/inferno/books/inferno_programming_with_limbo/Inferno_Programming_With_Limbo.pdf) и видимо на самого Роба Пайка. А писать, что «x является потомком y», при том, что на самом деле «x является потомком y и z» выглядит как приглашение к не очень здоровой дискуссии. Я лучше спать пойду.

но позже просто Оберона, от которого Активный отличается await-ом и мониторами - не очень сильно

В Go нет await и мониторов.

на АО каналы и горутины реализуются легко, равно как и в обратную сторону (await на го легко пишется точно, про мониторы я не так уверен). Т.е. плюс минус один хрен. Конечно, есть разница между АО и Го, но не такая уж и большая. Самое существенное отличие (думаю, что оно в пользу го) - это его система импортов и многофайловые модули. Притом если сравнивать АО и Го, то там ещё часть функционала из АО выкинута. И видимо из Лимбо тоже, хотя я не особо вникал, но мониторы в Лимбо есть.

А ещё проект Оберон повлиял на Plan9 (пруф http://doc.cat-v.org/inferno/books/inferno_programming_with_limbo/Inferno_Pro...) и видимо на самого Роба Пайка

Повлиял на Inferno — да. Но не на Alef/Limbo, так что пруфа я не вижу.

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

Off topic: я могу поинтересоваться с чем связана смена аватарки (я даже не сразу узнал пока подпись не увидел)? Это голубь мира ввиду последних Z-событий, marriage, что-то ещё?

Это голубь мира, каноничный, от Пикассо.

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

Настоящий программист напишет программу на Фортране на любом языке программирования (c)

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

Есть языки, в которых константы являются константами.

Во-первых, еще раз: есть реальность, она вот такая, ее нужно принять именно вот такой.

Простыми словами: когда вы в C++, то забудьте про то, что есть в других языках. Потому что вы в C++.

Точно так же как в Rust-е вы должны забыть как оно в Java, а в Java нужно забыть как оно в Ruby.

Костантность не выкастовывают, на константный объект не держат неконстантную ссылку.

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

В C++ вы не можете держать неконстантную ссылку на константный объект без UB.

Но проблема const в крестах в том, что она вроде как константа, но вроде как и не константа, но называется константа.

У C++ нет проблем с const, это у тех, кто общается с вами есть проблема – ваша упоротость.

Откуда я возьму идеи?

Простите, вы сейчас пытаетесь намекнуть на то, что способны сделать свой ЯП?

На самом деле есть кучу потенциальных задач, где понадобится менять поля объекта с «константным» значением

Приведите, пожалуйста, список из 4-5-6 случаев, где это нужно. Поскольку таких «потенциальных задач» целая «куча», то выжимка из 5-6 вариантов не должна составить вам труда.