юнионы в C++

Забавно, начал вчера смотреть интервью Гризмера и он сказал про ту вещь, от которой я был избавлен, отказавшись иметь дело с плюсами. А сказал он примерно следующее: я заметил, что иногда у нас возникал вопрос по языку. Каждый давал своё объяснение, и каждый раз оно было новое. Подключались всё новые люди. К концу второго дня появлялся гуру, который написал книжку по этому вопросу и всё объяснял. Его объяснение было на 2-3 страницы. И дальше (уже в моём вольном переложении, т.к. я забыл что он сказал) - плохо, когда язык становится самоцелью - он должен быть всего лишь инструментом для решения задач, а тут сложности в языке таковы, что их можно обсуждать два дня. У меня в принципе в телеге есть пункт «C++ слишком сложен», и вот вы к нему иллюстрацию создаёте прямо сейчас. Спасибо, ребят!

https://vk.com/video-155609632_456239126

Поздравляю со второй страницей (у всех же выставлено 500 постов на страницу?)

Нет, у меня уже 10-я страница - всё по умолчанию. Продолжая про сложность, нужно отметить дьявольское коварство этого языка. Программисты любят сложные задачи, поэтому, когда им дают сложный язык, они уже по самой своей природе склонны в него вляпаться. Если кто-то отказался от сложного языка, то его сразу можно обозвать неосилятором. А особенно здорово, когда сам факт освоения этого сложного языка добавляет денюжек. Но по сути-то это явление коррупционное, поэтому промышленность рождает всё новые и новые иные языки, чтобы обойти коррупционную схему, и обгрызает плюсы со всех сторон. То же и с Сями - они требуют аккуратности, программист должен быть аккуратным. Эта ловушка ещё опаснее, потому что она может подействовать и на заказчика. «Я пишу на Си и мне это удаётся, значит я аккуратен, значит, я хороший программист» - вот такой слоган может выставить любой сишник в качестве саморекламы. А кто не может или не хочет писать на Си - тот, дескать, недостаточно аккуратен и делать ему тогда в программировании нечего. Тоже такая псевдологика, против которой не так легко возразить. Хотя на самом деле промышленные процессы должны быть таковы, чтобы нефтеперегонный завод не взрывался от неаккуратности одного рабочего, а чтобы были защиты от дурака. Но это нужно быть самому не дураком, чтобы до этого дойти.

Опять же, есть свободные функции std::begin и std::end, но нет std::cbegin, std::cend.

И не надо. Нужно 2 функции begin, end, каждая из которых м.б. перегружена по константности возвращаемого итератора (а м.б. и не). Этот ваш C++ так позволяет?

Нет, по типу возвращаемого значения перегружать нельзя.

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

Извиняюсь, если похоже на тролинг.

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

Очень интересно, какая же идея у была Go?

Максимально простой в освоении и использовании язык, без жирного рантайма и приличной скоростью работы. Такой, чтобы среднестатический разработчик из Google мог освоить его за минимальное время и начать педалить код в продакшен не тратя месяцы/годы на зазубривание граблей C++ или Ынтырпрайз-паттернов Java.

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

Максимально простой в освоении и использовании язык, без жирного рантайма и приличной скоростью работы. Такой, чтобы среднестатический разработчик из Google мог освоить его за минимальное время и начать педалить код в продакшен не тратя месяцы/годы на зазубривание граблей C++ или Ынтырпрайз-паттернов Java.

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

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

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

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

После стопки-другой по случаю очередного дня программиста? Да запросто.

А вот оформить это во что-то, что затем перерастет хотя бы в прототип проекта – нет. Этого достигают лишь единицы.

Се ля ви.

После стопки-другой по случаю очередного дня программиста? Да запросто.

Очевидно, что это не стыкуется с вашим утверждением. Сделанным ранее.

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

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

Так что тут проблема в чем-либо другом.

Очевидно, что это не стыкуется с вашим утверждением.

Возможно, вы вкладываете в прочитанное какой-то свой смысл. Подозреваю, что слишком узкий.

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

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

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

в STL контейнеры наружу высовывают .begin(), .cbegin()

Ничего плохого не вижу: это лучше (практичней) чем «as_const» по коду разбрасывать налево / направо. Имхо.

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

Это уже не идея. Это уже проект.

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

В том, что при столкновении пониманий (моделей реальности) первой естественной психологической реакцией является Отрицание. Это нужно, чтобы отфильтровать заведомый буллшит, типа первой линии тех. поддержки. Ведь не зря же ты набрал весь свой опыт, думал над ним, чтобы так сразу отказаться от своих выводов. А опровергать каждый «бред» — оно тебе надо? Или даже не думал, а просто принимал оное как данность — а тут тебе говорят, что можно по-другому. Разрыв шаблона — это больно.

Это уж как вам угодно.

Суть в том, что создать свой язык уровня Go, Kotlin или Rust из здесь присутствующих смогут лишь единицы. И в их число, по моему мнению, buko3y не попадет. Как и den73. Как и я.

Суть в том, что создать свой язык уровня Go, Kotlin или Rust из здесь присутствующих смогут лишь единицы. И в их число, по моему мнению, buko3y не попадет. Как и den73. Как и я.

Вклад каждого важен! Мы же на opensource.ru

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

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

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

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

Неконстантый итератор умеет кастоваться в константый

vector<int> v;

vector<int>::const_iterator i = begin(v);
vector<int>::iterator a =  begin(v);

vector<int>::const_iterator i2 = v.begin();
vector<int>::iterator a2 = v.begin();

Поэтому Си и плюсы просто неперспективны.

Вполне возможно.

Вот только если в этой нише что и заменит Си, то только то, что протолкнут корпорации.

А у них свои интересы, никак не связанные с безопасностью, легкостью разработки или использованием готовых наработок.

Для них главное протолкнуть свою платформу. Вендор-лок.

Поэтому пока, все попытки проваливались.

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

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

Очень быстро работающая программа делающая неправильные вещи будет стоить вам денег. Много денег. Лучше так не делать.

При том процессоры всё быстрее и дешевле.

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

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

Исключительно в вашем мирке оторванном от реальности.

Поэтому Си и плюсы просто неперспективны.

Очень сильное утверждение, настолько притянутое за уши что просто не смешно.

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

Я этого не говорил.

Если есть N рисков, значит надо работать над сокращением всех и каждого.

Что вы знаете о рисках?

А ты предлагаешь «семь бед - один ответ».

И снова - я этого не говорил.

Невозможно ускорить процессором процесс крекинга нефти или синтеза азота.

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

Последние лет 10-20ть такие программы как правило пишутся на C++/CUDA. Упс?

Неконстантый итератор умеет кастоваться в константый

vector<int>::const_iterator i2 = v.begin();

Этот каст — мина замедленного действия. i2 выглядит, как константный итератор, крякает как константный итератор, но это не то, что должен делать пользователь с контейнером.

vector<int>::const_iterator i2_fixed = v.cbegin();

Ведь их реализации могут отличаться. По-крайней мере, надо явно использовать https://en.cppreference.com/w/cpp/types/add_cv

Я кстати пока не понимаю, возможно ли через них менять const-ness где-то внутри составного (из примитивов того же STL) типа

При том процессоры всё быстрее и дешевле

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

Подскажите реализацию Datalog

Нужно эффективно обрабатывать большие объёмы данных.

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

clojure после common lisp - насколько омерзительно и в чём именно?

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

Если ты взял С++, то тебе уже нужна скорость. Если ты можешь сказать

процессоры всё быстрее и дешевле [так что можно не париться]

то С++ тебе, скорее всего, не особо нужен.

Си и плюсы просто неперспективны.

Неперспективны для какой области разработки? Для HPC плюсы и CUDA являются стандартом де факто, фортран остался в старых проектах которые вынуждены поддерживать, либо в какой то дикой экзотике. Новых проектов на фортане единицы, старых которые в поддержке м.б. 10-20%.

HPC это сейсморазведка (поск нефти и газа), моделирование нефте и газодобычи включая гидроразрыв пласта, разработка новых материалов и лекарств (квантовая химия, метод функционала плотности), аддитивные технологии (лазерная печать из металлического порошка), разработка чипов (от трассировки до расчетов масок для литографии), т.н. цифровые двойники для сложных техпроцессов и т.д. и т.п. Все бол-мен новое и сложно что сейчас производится сначала моделируется, и коды для моделирования пишутся на С++/CUDA. Не потому что плюсы такой замечательный ЯП (плюсы ужасны) а потому что ничего лучше для таких задач пока не нашлось.

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

Не потому что плюсы такой замечательный ЯП (плюсы ужасны) а потому что ничего лучше для таких задач пока не нашлось.

Вы его агитируете занятся разработкой ЯП для этой ниши?

Как тут не вспомнить перспективный cobol с такими аргументами. Хотя мое мнение что C/C++ еще долго жить.

Нет, я ему пытаюсь (уже в третий что ли раз) объяснить что ИТ разное, и для разных задач нужны разные инструменты/ЯП. И то что он не видит куда приложить плюсы это не проблема плюсов а проблема его кругозора.

Этот каст — мина замедленного действия. i2 выглядит, как константный итератор, крякает как константный итератор, но это не то, что должен делать пользователь с контейнером.

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

class Iterator {
   operator const_iterator();
}

Ну и оба итератора являются специализациями одного шаблона итератора.

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

В области HPC все куда проще. Был Фортран, потом пришли плюсы. Остальные (хаскели всякие) не шмогли.

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

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

Время реакции тесно связано с производительностью. Хотя и не полностью коррелирует.

И если безопасность конфликтует с производительность, то совсем не факт, что она конфликтует со временем реакции.

Так что лучше не переменивайте. Вдруг что и сделает. :)

Ну и оба итератора являются специализациями одного шаблона итератора.

Это я понимаю

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

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

А кажется понял о чем речь, о каком-то пользовательском контейнере со своими итераторами, который не следуют стд’шной стратегии и cbegin() у него это очень сильно не begin(). Ну, по-моему, тогда вообще не надо под стд косить. Когда делал подобное (юникодную строку), то повторял логику STL. Кстати, перегрузку по возвращаемому типу можно так делать:

struct S {
   operator int();
   operator double();
   operator Something();
};

Ну и оба итератора являются специализациями одного шаблона итератора.

Между прочим, тот факт, что тег константности теперь живёт и в типе, и в core language — тоже результат сишного наследия, насколько я понимаю.

Если уж упарываться по шаблонам, почему просто не

int, const<int> или даже mutable<const<int>> (ну а вдруг понадобиться?)

Этот каст — мина замедленного действия. i2 выглядит, как константный итератор, крякает как константный итератор, но это не то, что должен делать пользователь с контейнером.

Не вижу опасности: как по мне это эквиваленты. В c++98 cbegin() / cend() вообще не было, и ничего - жили же как-то.

Ведь их реализации могут отличаться.

Исключительно в теории (нужно специально постараться - тут уж каждый ССЗБ). На практике - не встречал.

фортран остался в старых проектах

Справедливости ради должен заметить что мы до сих пор используем одну коммерческую фортрановскую библиотечку с numerical algos. Попытки написать своё (те её части которые нам нужны) ни к чему хорошему пока не привели.

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

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

Ваша же ниша не заточена не на безопасность, а заточена на производительность и удобство.

Гениальная затея - написать неправильную расчётную программу. Это даже ещё лучше, чем написать неправильную программу управления. Плюсы ещё лучше подходят.

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

Так что лучше не переменивайте. Вдруг что и сделает. :)

Да ничего уже и делать особо не надо. Более хороших языков, чем Си/Си++ достаточно много.

Эти же самые люди будут писать гневные телеги про жирный электрон.

Электрон может и жирный, но VS Code меня устраивает, в то время как IDE, написанные на Java - слишком тормозные, а написанные на C++ - просто слишком убогие (потому что на убогом языке программы пишутся медленнее, не осиливают сделать функционал, разве только Микрософт осилил). Т.е. к примеру написание IDE - не ниша для С++. Написание компиляторов - не ниша для С++, потому что в компиляторе куча сложных и ссылающихся друг на друга объектов, а реальное время не нужно. Их лучше на лишпике писать или на го, или на шарпе, а сейчас и на жабе можно наверное, т.е. на языке со сборкой мусора и AOT компиляцией. Числодробилки, внезапно, пишут тоже и на лиспе, и даже на Обероне (допилив сам Оберон, т.к. его легко расширять). То, что что-то там стало стандартом де-факто не означает, что оно хорошее. Вон JS стандарт де-факто для веб-страниц, но это же не превращает его в нормальный язык.

Между прочим, тот факт, что тег константности теперь живёт и в типе, и в core language — тоже результат сишного наследия, насколько я понимаю.

Нет, всё не так. Если у нас два итератора:

It it;
const It cit;

то второй нельзя будет итерировать (он ведь константый), мы хотим другого - возврат константного объекта при разыменовывании, поэтому делаем отдельный типы, которые сами неконстанты:

It it;
const_It cit;

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

Гениальная затея - написать неправильную расчётную программу. Это даже ещё лучше, чем написать неправильную программу управления. Плюсы ещё лучше подходят.

Небезопасная != неправильная.

Это вопервых.

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

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

Ну и напоследок. Большинство полезных задач связанных с ИИ - это механизм сканирования в поисках мест интересных для ученых.

Типа «наша система анализа выявила еще 100 перспективных химических соединений, вот табличка с приоритетами по…» :)

Вот это как раз фантазии

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

В остальном ты больше хамишь, чем пишешь что-то осмысленное, даже дочитывать не стал.

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

Более хороших языков, чем Си/Си++ достаточно много.

Неправильно прозвучит ввиду последних событий, но «Искандеры улыбнулись». Удачи на поприще.

Мне, честно сказать, наплевать, что ты про меня думаешь.

Да ничего уже и делать особо не надо. Более хороших языков, чем Си/Си++ достаточно много.

Жаль. А то Си и Си++ не просто так остаются в своих нишах.

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

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

Или посто потрындеть захотелось?

Небезопасная != неправильная.

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