Теме компилятора ключевая в этом проекте. Я позже её более подробно опишу, но сейчас в дополнение к крестам.
Мир
Не думаю, что здесь необходимы какие-то особые пояснения - всё аналогично. Весь человеческий капитал сосредоточен в мире С/С++, а значит никакого компилятора ни у кого, кроме них, быть не может. Но. Мы помним, что мир С/С++ во многом раб мира рабов. Поэтому адепты дерьма уже давно поняли, что с компилятором работает всё та же схема.
С/С++ компилятор был подроблен на части, вынужден был жрать дерьмо и всё, опять же, во имя того, чтобы мир С/С++ создавал компиляторы для бездарной скриптухи. И венец творения:
clang/llvm
Здесь наиболее показатель пример llvm. Родился как продукт мира С/С++ призванный служить скриптухе. Обделался. Скриптуха оказалась ни на что не способной. Был создан clang, а далее llvm стал развиваться как его часть.
И всё точно так же. Существуют такие же внутренние противоречия, дяди так же обеспечивают существование скриптухи за своё счёт потому, что это позволяет им поддерживать мир С/си с классами. Так же через это дяди эксплуатирую других дядей. Создав такую систему, что если другим дядям нужно что-то сделать для С/С++ - они вынуждены делать, в том числе, и для остального дерьма.
В данном случае меня это не особо интересует - всё это очевидно. Остановлюсь только на том, какие проблемы это производит для нас(последователей пути пацана). Как-то многосложно разбирать это сейчас не выйдет - необходимо описать множество базовых концепций, без понимания которых понять что-то будет почти невозможно. Но кратко основные проблемы я обозначу.
gcc
gcc архитектурно лучше, но только как компилятор. Во всём остальном всё те же проблемы, а семантических возможностей вообще нет.
clang
Написан как дерьмо. Это целиком и полностью дырявое, убогое дерьмо.
Его ast почти целиком и полностью бесполезно
Если кратко, то оно содержит очень мало семантической информации. В целом оно создано только для одного - обойти его и сгенерировать ir. Обходит оно эту проблему следующим образом. Есть некая помойка - sema. Это тысячи всяких дырявых состояний и методов, которые произвольным образом в момент парсинга инициализируются и вызываются. После того, как ноды будут сгенерированы, шаблоны инстанцированы и прочее - sema просирается и вся информация тоже. В ast ничего не попадаёт, кроме совсем примитивной херни.
Таким образом ast ничего не знает о семантике, а значит никак свою согласованность не отслеживает. Да что там говорить - даже на уровне sema никакая консистентность не отслеживается. Просирается всё. Скоупы, что и из чего было сгенерированы, карты отображения шаблона на инстанс и прочее.
Эта одна из причин почему ast нельзя изменить(не запоров его), почему нельзя их друг с другом мержить. Там есть ещё одна причина всему этому.
Существует базовый паттерн замены используемых сущностей на их идентификаторы. Это позволяет очень просто их шарить и поддерживать один инстанс каждой сущности на ast. Реализовано это там, очевидно, как говно. На базе убого аллокатора дерьма и голых указателях. Поэтому это дерьмо постоянно течёт и сегфолтится. Никакое время жизни объектов не отслеживается, из-за того, что везде и всюду указатели - никто не знает и не понимает что за что отвечает. Как и никакие объекты не отвечают за свою согласованность - это просто набор указателей, с произвольной семантикой. И пишут это, как я уже говорил, совсем дошколята. Там чего только не увидишь, в том числе и векторы в внутри смартпоинтеров.
Соответственно, по этой причине мы никак не можем смержить ast. Кое какие костыли там реализованы и кое как подставить кусок ast можно(сверху). Но, очевидно, работает иногда(для top-level) и лишь чудом(как всегда). А в тех случаях, когда работает - работает лишь потому, что С++ - это odr-дерьмо. Т.е. реализовать что-то не odr невозможно, а язык с odr - мусор.
Из-за отсутствия возможности мутировать ast - невозможен инкрементальный парсинг. А без инкрементального парсинга - язык говно. Добавить его туда невозможно.
Получить какую-то информацию можно только только на стадии парсинга. Но для ide такое не подходит. Нам требуется эта информация постоянно. Расширить это ast-дерьма не представляется возможным. Для получения полной информации - нужно использовать своё ast.
Никакого автодополнения нет. Оно реализовано через убогие костыли на стадии парсинга. А это значит, что никакая информация недоступна. Причём, парсинг очень тормозной и нужно парсить всё. Существуют всякие костыли для его ускорения, но всё равно он тормозит, а костыли просто заставляет его терять информацию. Т.е. получить всё, что определено после контекста дополнения - нельзя. Остальные костыли снижают качество окружающего контекста.
Именно поэтому никакое нормальное автодополнение в шланге дерьма - мы никогда не получим. А реализовать автодополнение в шаблонах - попросту невозможно.
Резюмируя. Мало того, что ast шланга дерьмо. Его ещё и исправить невозможно. Оно ущербно by-design и это не изменить, даже полностью его переписав.
результат
Компилятора у нас нет. И с этим ничего не поделать. Проблем там ещё больше, но как уже говорил - разберу их отдельно. Выводы так будут отдельно.
Слыш, самозванец, ану оправдывайся. Почему такой код даже не компилируется?
ОтветитьУдалить#include
#include
#include
#include
#include
namespace hana = boost::hana;
using namespace hana::literals;
#define SUVT_COUNT 8
struct SUVT {
int perekluchatel;
union {
struct {
uint64_t u64;
};
struct {
uint8_t u8;
};
struct {
char* string;
};
};
};
int main() {
srand(time(NULL));
auto s = hana::iterate([](auto s) {
int type = rand() % 3;
switch (type) {
case 0:
return hana::append(s, SUVT{ perekluchatel: type, u64: rand() });
break;
case 1:
return hana::append(s, SUVT{ perekluchatel: type, u8: rand() % 256 });
break;
}
return hana::append(s, SUVT{ perekluchatel: type, string: "pisxka" });
}, hana::make_tuple());
auto t = hana::filter(s, [](auto suvt) { return suvt.perekluchatel ? hana::false_c : hana::true_c; });
hana::for_each(t, [](auto suvt) {
switch (suvt.perekluchatel) {
case 0:
printf("%lld\n", suvt.u64);
break;
case 1:
printf("%hd\n", suvt.u8);
break;
case 2:
printf("%s\n", suvt.string);
break;
}
});
return 0;
}
Тут варианта два. Либо я анскильная пыль запартная. Либо твоя constexpr-хуйня — бесполезное говно, которое не может работать с внешними данными.
А если SUVT_COUNT поднять, скажем, до 256, то случается комбинаторный взрыв и компилятор схавывает гигабайты рамы на хэллоуворлде. Пиздец-то какой.
Фу, блядь, ну и движок. Нельзя было сделать селф-хостед блог и засунуть в него хотя бы Disqus какой-то, который умеет в тег для кода?
УдалитьНа, жри https://pastebin.com/CsCd61mi
Объясни пожалуйста зачем ты написал этот вырвиглазный пиздец, когда на чистом Си можно написать абсолютно эквивалентный код, но короче и яснее?
УдалитьЭто как пример пифагоровых троек на ренжах C++20, который призван показать выдающиеся способности крестов, а на деле - ебанутый и абсолютно бесполезный в 99% случаев пиздец.
>на чистом Си можно написать абсолютно эквивалентный код
УдалитьА как же ФУНДАМЕНТАЛЬНАЯ СИСТЕМА ТИПОВ, вот это всё?
Три(!) сука месяца не мочь написать нормальный блог, имея в распоряжении с десяток специально заточенных под это технологий... Это пиздец и ебучее днище..
УдалитьМожет и мне кресты поучить? Кто посоветует?
ОтветитьУдалитьЧто-то царь там совсем пропал. Видать свой сайт на С++ пишет. В делах весь. Оптимизирует.
ОтветитьУдалитьЧат для настоящих мужиков: http://fintank.ru:8080/s/main/
ОтветитьУдалитьРеальный продукт, в отличие от мифического бложика на цпп от Царя Трепла
Царь, насвай. Мне пофигу. Фуфлом оказался. Свой бложик, запартное, не осилил. Слился. Лалка. Только кукорекать и умеет. Раб школьников, что собрал вокруг себя. Только и знает, что полировать им очки. И если что -- обижается, аки девица. Ещё что-то про поцанские темы втирал. В архитектуру не может. Ничего не может. Сразу видно школотрона переростка. Великовозрастный детина.
ОтветитьУдалить