- 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
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
https://habr.com/ru/article/448466/
*/
А последние пару лет набирает популярность boost.hana. Это boost.fusion,
но с constexpr'ом и лямбдами. Автор hana, Луис Дионе (Louis Dionne),
используя на полную мощь все возможности новых стандартов, в некотором
смысле очеловечил метапрограммирование. С помощью hana всяческие
манипуляции с типами, их кортежами, отображениями, а также компайл- и
рантайм-работа с ними обрели практически человеческое лицо и читаемый
вид. Ну, с поправкой на синтаксис C++, разумеется. Вот, например, как выглядит
универсальный сериализатор структур, написанный с помощью hana:
*/
// 1. Give introspection capabilities to 'Person'
struct Person {
BOOST_HANA_DEFINE_STRUCT(Person,
(std::string, name),
(int, age)
);
};
// 2. Write a generic serializer (bear with std::ostream for the example)
auto serialize = [](std::ostream& os, auto const& object) {
hana::for_each(hana::members(object), [&](auto member) {
os << member << std::endl;
});
};
// 3. Use it
Person john{"John", 30};
serialize(std::cout, john);
/*
Ну да, структуры приходится описывать особым образом. А кому сейчас легко?
И тут хочется также отметить библиотеку tinyrefl за авторством Manu Sánchez
(Мануэля Санчеса). Довольно неплохая попытка принести в мир C++-разработки
статическую рефлексию без расширения компилятора. Для своей работы библиотека
требует стороннюю утилиту (cppast), но зато предоставляет довольно удобный доступ
к информации о структурах, которую можно использовать в процессе разработки
программы. Преимущество этой библиотеки (по сравнению с другими) в том, что для
работы с ней не надо использовать «птичий язык», а элементы структур (как и сами
структуры) можно произвольным образом атрибутировать прямо в исходном коде:
*/
struct [[serializable]] Person {
std::string name;
int age;
};
template<typename Class>
auto serialize(std::ostream& os, Class&& object) -> std::enable_if_t<
tinyrefl::has_metadata<std::decay_t<Class>>() &&
tinyrefl::has_attribute<std::decay_t<Class>>("interesting"),
std::ostream&>
{
tinyrefl::visit_member_variables(object, [&os](const auto& /* name */, const auto& var) {
os << var << std::endl;
});
return equal;
}
/*
Таких примеров можно привести ещё много (или найти на гитхабе или гитлабе).
Объединяет все эти библиотеки и инструменты одна особенность: значительно
облегчая жизнь своим пользователям, они имеют такую реализацию, что остаётся
лишь предполагать, какое количество страданий испытали их разработчики. Достаточно
заглянуть в реализацию, увидеть забор из ifdef'ов и угловых скобок — и всё понятно.
Нередко эти реализации делаются на грани возможностей компиляторов. workaround'ы
банальных ошибок (или особенностей реализации языка конкретной версии конкретного
компилятора с конкретными флагами) здорово раздувают их код. Желание поддерживать
несколько стандартов сразу заставляет придумывать зубодробильные конструкции.
Безусловно, простая попытка реализовать что-нибудь подобное здорово поднимает уровень
владения языком (иногда — и самооценку). Но в какой-то момент, после многочасовой возни
с очередной ошибкой, или непроходящим тестом, или крэшем компилятора руки опускаются,
хочется плюнуть и бросить, ибо силы бороться иссякают.
*/
Follow us!
> Но это, как говаривал Барон, ещё не все. Однажды в мир разработки C++ пришёл clang со своим фронтендом (а чуть позже — с libtooling), и мир изменился, заиграл новыми красками. Появилась надежда. Ибо появился инструмент, позволяющий относительно просто (относительно!) анализировать исходные тексты на C++ и что-нибудь с результатами этого анализа делать. Появились (и стали набирать популярность) утилиты типа clang tidy, clang format, clang static analyser и прочие. А некоторые разработчики приспособили clang frontend для решения задач рефлексии. Так, скажем, работают упомянутые выше cppast (за авторством Jonathan Müller) и tinyrefl на её базе. Так работает автопрограммист, используемый в нашей компании для кодогенерации (или его open-source-аналог).
> Разумеется, и до появления clang писались генераторы на основе исходного кода C++. Кто-то использовал для этого Python с самописными парсерами, кто-то разбирал C++ с помощью regexp'ов. Кто-то, как автор этой статьи, писал самопальный парсер на C++. Но, полагаю, с развитием инструментария это будет уходить в прошлое.
> Идея проста. Берётся исходный текст на C++ (например, объявления структур), пропускается через clang frontend, и на основе полученного AST генерируется новый исходный текст.
Именно поэтому.
Я уже не один раз высказывал эту гениальную мысль на страницах говнокода
http://govnokod.ru/25397#comment460314
http://govnokod.ru/25407#comment461860
> Currently the performance is really bad, there is a talk to make wasm based jit machine in a compiler to accelerate constexpr, but problem is keeping the undefined behavior-less behavior :)
бггг
> We really need an allocation mechanism in constexpr. But I don't need to return the allocated object outside of a constexpr function...
> Is std::array constexpr? If so, can it decay to a ptr and be cast to any type at will?
> You can’t cast to any type in constexpr.
https://memepedia.ru/wp-content/uploads/2017/07/хохочущий-испанец.jpg
> I really need C++ to be able generate goto-s and labels.
ох блядь... make me unsee it
> Макросы (C++), шаблоны (C++98), свойства типов и constexpr'ы (C++11), концепты (C++20) — с каждым новым стандартом и витком развития язык предоставляет разработчику всё больше информации о том, что творится в недрах компилятора: начиная от манипуляции на уровне лексем и заканчивая compile-time-вычислениями и декларативным описанием свойств пользовательских типов. Логичное завершение (или продолжение?) этой цепочки — предоставление разработчику возможности напрямую манипулировать процессом компиляции кода на уровне AST. И такое предложение уже есть.
Ох б%?№^& сука... ну охуеть теперь. Лучше сделайте новый язык, а этот выкиньте нахуй. Сделайте диалект лиспа с байтоебством и без GC. Я довольно хуево себе представляю то, каким образом с текущим крестоговносинтаксисом вы буделе делать манипуляции с AST
И с UB'ами во время конпеляции!
Но это уже будут не кресты. Вся суть крестов - прикручивать к ним новую хуйню не ломая совместимость со старой. Это как игра про башню из кирпичиков.
Как строить башню из брикетов спрессованного дерьма. http://toplivnye-brikety.mya5.ru/toplivnye-brikety-iz-navoza/
Эту башню еще постоянно перекашивает под собственным весом, и стоит она на таком же самом фундаменте из говна. И даже если эту говноконструкцию идеально сбалансируют и стабилизируют - всё равно она останется говном и будет вонять
В предложении про метаклассы это выглядело довольно просто - из constexpr блока можно позвать оператор -> {...} который высрет хуйню из скобок в родительский блок и раскроет в ней $переменные. Ну и оператор $, которым можно получить constexpr инфу о типе.
Конечно как всегда с кучей ебанутых ограничений и костылей. Но они почти придумали лисповые макросы :)
Или я нихуя не понял, или это говно никакого (или почти никакого) отношения к лисповым макросам не имеет.
Вот представим себе некий гомоиконный язык, в котором нет циклов for но есть ite и goto. И допустим у нас будет функция, которая считает сумму чисел от 1 до 10
Ну и если захотим, можно впилить в язык цикл for, который будет трансформироваться в конструкцию с этим условием с goto и присвоением, типа вот:
и всё это достаточно легко будет делаться, мы просто рассматриваем нашу программу как связный список связных списков, больше нихуя нет, мы просто пишем код (макрос), который при вставке в код for вот с такими-то аргументами трансформируется/раскрывается вот в такой-то код, для этого "for" мы просто пишем код, который конструирует на основе аргументов какой-то новый код через связные списки связных списков и ... и все. Это - ПРОСТО.
Когда же я читаю про метаклассы то это вообще хуйня какая-то. Классы какие-то, зачем мне вообще классы? Вот представим на минуту, что из крестов выпилили нахер for(), while() циклы, но зато есть if() и goto label, через эти метаклассы можно запилить for()? Если нет, при чем тут тогда лисповые макросы?
> A metaclass is written as a compile-time constexpr function that takes meta::type parameters, which are passed with reference semantics
...
> In the latter form, it can be used to use the values or abstract state of objects of meta::type.
...
> A pure base_class is a class that has no instance data, is not copyable, and whose a destructor is either public and virtual or protected and nonvirtual. Unlike an interface, it can have nonpublic and nonvirtual functions.
...
блядь, сколько хуйни на ровном месте. Какие-то pure base_class, какие-то методы, классы, хуяссы, констэкспры, meta::type. ЗАЧЕМ? ЗАЧЕМ ЭТО ВСЁ? Как это соотносится с лисповыми макросами?
З.Ы. Я одну из первых версий пропозала читал, возможно сейчас там всё поменялось.
ahead —– отмечает безусловный переход вперёд;
if —– отмечает условный переход вперёд;
then —– разрешает переход вперёд;
begin —– отмечает переход назад;
until —– разрешает условный переход назад;
again —– разрешает безусловный переход назад;
cs-pick и cs-roll для работы со стеком потока управления.
Всё остальное можно реализовать поверх них:https://ideone.com/00PGzJ
> требует стороннюю утилиту
Мне одному кажется, что это и есть расширение конпелятора?
Божечки, почему программисты стабильно изобретают колесо и текут от этого?
return (n==0) ? acc : fac_times(n - 1, acc * n);
}
int factorial (int n) {
return fac_times (n, 1);
}
Тут проблема не в отсутствии гомоиконности, а в том, что только полному отморозку придёт в голову использовать в качестве схемы данных крестомакросню:
– Как нам распарсить этот бинарный блоб, г-н Рахитектов?
– Для начала чекаутни ревизию fd3fgsf4 нашего проекта и грепни на 'BOOST_HANA_DEFINE_STRUCT(Sosnoolee'
Надо чтобы ASN.1!