- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
/* https://habr.com/ru/company/jugru/blog/524600/
Давайте теперь поговорим о метаклассах, коль скоро ваш вопрос был в первую очередь о них.
Для их реализации было необходимо три фундаментальных нововведения. Во-первых, программирование
во время компиляции. На момент начала работы над метаклассами оно частично присутствовало в
constexpr, но тогда оно было ещё сырое и не до конца обобщённое. Во-вторых, была необходима
рефлексия, по которой тогда только-только появились первые предложения, и рассчитывать на неё
было рискованно. В-третьих, нужна была генерация кода, создание исходного кода C++ во время
компиляции — на тот момент в C++ этого ещё ни разу не делали.
Но при наличии этих трёх предпосылок метаклассы становятся просто синтаксическим сахаром,
который во время компиляции применяет функцию рефлексии и генерации кода. Поэтому в
первоначальной статье по метаклассам (P0707) также написано об этих трёх вещах: рефлексии,
полном программировании во время компиляции, то есть возможности выполнять любой код C++
во время компиляции, и генерации кода C++; ничего этого на тот момент в языке не было.
Самым важным шагом в этом направлении стало добавление программирования во время компиляции.
Это значит, что вторая предпосылка метаклассов в C++20 почти закончена. Функции consteval
с гарантированным выполнением во время компиляции на самом деле были предложены именно в
статье, которую я только что упомянул. На основе моей статьи Эндрю Саттон (Andrew Sutton)
сделал реализацию метаклассов в Clang, с помощью которой были написаны consteval и некоторые
другие фичи C++20.
В общем, с программированием во время компиляции дела обстоят хорошо. Что касается рефлексии,
она входит в список семи приоритетов для C++23. Даже без учёта нарушений из-за COVID-19 я
сомневаюсь, что рефлексию завершат к 2023 году, но ей точно будет уделяться много усилий.
Это не может не радовать. Над генерацией сейчас тоже работают Дэвид Вандевурд и, опять-таки, Эндрю Саттон.
Когда рефлексия, consteval и генерация станут частью стандарта, для добавления метаклассов
будет достаточно заявки на пяти страницах, в которой мы просто поблагодарим за реализацию
этих трёх предпосылок, и предложим добавить поверх них синтаксический сахар, который позволит
во времени компиляции применять функцию к классу. В общем, в этой области сделано уже очень
многое, но, как видите, это проект, требующий много лет для завершения. Мне пришлось разбить
его на несколько более мелких заявок, чтобы вся работа не была забракована из-за одного
неудачного сегмента. Несмотря на это, мы всегда учитывали конечную цель — метаклассы; и мы
всегда ориентировались на определённый вариант использования.
Легковесная обработка исключений — более новый проект, я впервые предложил её комитету в 2018 году.
В отличие от метаклассов, на начальном этапе диалога прототипа ещё не было, и я хотел узнать, готов
ли комитет вообще двигаться в этом направлении. С самого начала мы получили положительную реакцию,
а также некоторые технические вопросы. В следующем году мы планируем начать работу над прототипом.
Когда прототип будет готов и мы сможем ответить на эти технические вопросы, мы составим более подробную заявку.
Наконец, нужно сказать ещё об одном проекте, обсуждение которого началось только в феврале этого года.
Это было в Праге на встрече юзер-группы, её запись выложена на YouTube. Речь идёт о передаче параметров и
инициализации. Здесь используется подмножество правил статического анализа, которые использовались для
Lifetime. Я уже подготовил об этом статью (под номером 708), но прежде чем подать её комитету, мне необходимо
будет создать прототип.
*/
Follow us!
> Любому другому конкуренту C++ нужно будет уделить совместимости значительно больше внимания, чем это делается сейчас. Я не говорю, что другой язык вообще не может занять место C++ без обратной совместимости, просто это будет значительно более долгий процесс.
Между строк можно прочитать что-то типа "ну да C++ то еще говно, но ведь сколько кода на нем написано! Вы что, будете его весь переписывать???"
В остальных случаях именно кресты мимикрируют под чужие интерфейсы - C, COM, JNI, PyObject, Lua и т.п.
Совместимость же на уровне исходника - это вообще фентези какое-то, примерно как драконы и единороги.
Бинарно конечно кресты даже сами с собой не совместимы
Хочу обратить внимание, мы очень рады... тьфублядь. Что это за хуйня вообще? Точно как этот Гофман https://www.youtube.com/watch?v=ZngXFXKeYcU
Теперь-то ясно, почему в стандарте крестоговна столько хуйни
Теперь, когда мы по очереди изложили свои мысли, перейдём к проекту. Мне хотелось бы, чтобы его сразу можно было смотреть на YouTube, и поэтому, если кто-то захочет добавить что- то от себя – пожалуйста. Что касается описанных обстоятельств, то они крайне важны. Я не первый год занимаюсь подобными проектами, и вы все знаете, что происходит при утечке информации. Поэтому мне кажется, что сейчас не время использовать этот метод. Это сделано специально, чтобы максимально обезопасить нас от разных негативных моментов. Есть люди, которые сейчас усиленно работают над этим проектом, но из-за технических сложностей они не смогут принять участия в его выполнении. Это, конечно, не снимает с них ответственности – эти ребята, безусловно, лучшие из лучших, и я хотел бы попросить у них прощения за то, что не даю им возможности сделать этот проект полностью реальным для остальных.
#вореции #порфирьевич
Насколько я знаю, на этот принцип давным-давно положен хер. Пример с корутинами (которые требуют хип) это неплохо показывает.
>
> Больше того, нам в неё хорошо бы ещё включить вещи вроде JSON и HTTP. Так что хотя в последнее время в неё добавляется много важных вещей, нам ещё есть куда расти
Предлагаю еще включить XML, JS и PHP. Если серьезно, прежде чем включить HTTP, надо б для начала с сетью разобраться на разных платформах, а на конец 2020 года еще нихуя нет
Именно поэтому я за Си.
> И всё же наша библиотека ещё слишком маленькая.
Для микроконтроллеров - нет.
Ну вот кстати да. В неё изначально натащили всякого говна про stdin и stdout, которое приходится выбрасывать целиком, вместе с полезными частями крестовой либы.
А поддержка сети, json или функции бесселя тебе на контроллерах никак бы не помешали, они рантайм не раздувают если их не юзать. В отличие от std::cin.
Плюс без рантайма ты потеряешь нетривиальные конструкторы у глобалок. И с этим придётся смириться либо самому эту механику восстанавливать.
Вообще, эта хуйня еще нужна для избежания рекурсивной инициализации, подробности тут https://manishearth.github.io/blog/2015/06/26/adventures-in-systems-programming-c-plus-plus-local-statics/ - но и для этого можно добавить опцию "--тут_нет_рекурсивной_инициализации" чтоб компилятор хуйни не генерил (еще компилятор теоретически может попробовать доказать, что рекурсивной инициализации в каком-то конкретном случае происходить не может в принципе, но компиляторы для этого видимо слишком тупые).
-fno-threadsafe-statics разве не помогает?
Не, всё равно какие-то гуарды вставляет. Хочу чтоб вообще без всей этой хуйни.
Компиляторы не могут сгенерить такую функцию, которая будет вызываться без накладных расходов на проверку, если уже понятно, что функция уже как минимум один раз вызывалась?
Пример: https://godbolt.org/z/b9GbTx
Будь компилятор умнее, он бы мог сделать функцию, в которой проверка не производится. Хотя если компилятору разрешить ту функцию инлайнить, проверка этого гуарда была б только один раз, хоть что-то положитльное
Ты можешь сделать глобальный инстанс класса и позвать у него init() явно (ну или таки восстановить механику глобальных конструкторов, она простая), а потом без всяких проверок звать остальные методы, которые юзают его поля.
Как ты себе это представляешь?
* И в которых есть статические пельменные, конечно.
У меня тоже однажды был партнёр один, который "бля я только юдипи могу, стек тисипи не влезет". Хотя даже если бы сук на 1к рублей у него косты бы выросли (а не 6 центов) и он бы въебал девайс с поддержкой 4ГБ рам, а не хуйней на 8 килобайтов!, это было бы нормально. Обходите стороной таких мудаков, это не лечится
Свой особенный мирок. Ходить в трусах на размер меньше, чем надо, и хвалиться об этом.
UDP хватит всем.
Что только люди не делают, чтобы не юзать класс вместо функции.
Только запатчить jmp надо очень аккуратно и атомарно. Чтобы другие треды либо успели его запрефетчить и ушли на лочку или уже увидели нормальный код.
Зато работать будет, в отличие от. Тем более этот кусок может быть один на все такие функции если заюзать call вместо jmp.
> сам себя перезатрет
Чем он блядь себя перезатрёт? Где он возьмёт инфу для этого? Из сети? С диска?
Очевидно - с диска подгрузит вореант функций без хуйни, и хуйнет его на место себя. Впрочем, можно и иные вореанты придумать, например jit-нуть некую хуйню из LLVM байткода который слегка запатчили
Хотя конечно ясен хрен, что всё это крохоборство нахуй никому не всралось.
Это вообще тухлая идея, имхо. Почему я пытался всего одну инструкцию затирать - jmp, call и т.п.? А потому что во время самомудификации у тебя соседние ядра в конвейер/кеш затянут половину старого кода, а потом внезапно продолжат исполнять новый. И кровь-кишки.
С одной инструкцией это вроде бы должно прокатить т.к. ядро либо увидит jmp и съебёт из опасной зоны либо уже увидит новый код. Ну и разумеется этот jmp не должен пересекать границы кешлайна и должен быть перезаписан атомарно.
Ага, таблички с таймингами команд ещё имели смысл, как сейчас на AVR.
Ну на AVR и ARM Cortex более-менее честная низкоуровневая питушня. Хоть и слегка запайплайненная. И такты описаны, можешь считать.
Хоть какое-то чувство контроля над железом. Ну и там нету недокументированной хуйни в духе ME.
Хоть строй машину времени, и лети в 1989-й год..
А где в это время будет rip?
Можно сделать исполняемый стек, в него насрать опкодами и выполнять их оттуда.
> мы можем построить некий граф достижимостей таких-то вызовов таких-то функций
Для примеров в пятнадцать строчек — да, можем. Для любых бульмень реальных проектов — уже нет.
Многабукав. Автоматически вореции.
Какая профдеформация )))