Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Perform preprocessing as a separate pass before compilation. By default, GCC performs preprocessing as an integrated part of input tokenization and parsing. If this option is provided, the appropriate language front end (cc1, cc1plus, or cc1obj for C, C++, and Objective-C, respectively) is instead invoked twice, once for preprocessing only and once for actual compilation of the preprocessed input. This option may be useful in conjunction with the -B or -wrapper options to specify an alternate preprocessor or perform additional processing of the program source between normal preprocessing and compilation.
У GCC всё запутано. Бинарники «gcc» и «cpp» — это всего лишь оболочки, которые запускают бинарники «cc1», «cc1plus» или «cc1obj», лежащие в /lib/gcc. Вот этот вот «cc1» и есть препроцессор и конпелятор для сишки.
А есть еще collect2, который является частью GCC, но в отдельном бинарнике. А есть /usr/bin/as, /usr/bin/ld из бинутилсов, которые уже не являются частью GCC.
> в MSVC препроцессор и компилятор в один бинарь запихали
Кстати, с этим связана интересная фишка, с которой я недавно столкнулась при портировании кода под линукс.
В MSVC имя функции это литерал. А в остальных конпеляторах это локальный массив, как и требует стандарт. В итоге в MSVC имя можно было конкатенировать с чем-то ещё, а в других конпеляторах -- нет.
Да, по стандарту там никакой магии не должно быть. Просто в начале каждой функции есть массивчик __func__, который содержит её имя. А дальше конпелятор с линкером его выкинут, если ты им не воспользовался.
В MSVC же выебнулись и сделали его псевдо-макросом, который раскрывается в литерал. Что, конечно, удобнее.
> __FUNCTION__
Ня нужен. Это древнее нястандартное расширение. Правильные девочки-волшебняцы использнуют "__func__" (который по Стандарту ня макрос, кстати).
> cl /E у MS умеет показать выхлоп после процессирования
И что он покажет с этой вот __FUNCTION__ ": " ?
https://docs.microsoft.com/ru-ru/cpp/preprocessor/predefined-macros?view=msvc-160 __FUNCTION__ определяется как строковый литерал, содержащий недекорированное имя включающей функции. Макрос определен только в пределах функции. Макрос __FUNCTION__ не разворачивается, если используется параметр компилятора /EP или /P . Пример использования см. в разделе для макроса __FUNCDNAME__.
Про /E там ничего не сказано.
Препроцессор GCC эту __FUNCTION__ ни во что не раскрывает т.к. языка Си он не знает
Тут всё тупо. «uts» — это ещё не имя функции. Это произвольный текст, семантика которого ещё не ясна. Только в месте вызова r(p) макрос начнёт разворачиваться, и там «p ## uts» станет именем функции.
clang/llvm
Здесь наиболее показатель пример llvm. Родился как продукт мира С/С++ призванный служить скриптухе. Обделался.
Скриптуха оказалась ни на что не способной. Был создан clang, а далее llvm стал развиваться как его часть.
И всё точно так же. Существуют такие же внутренние противоречия, дяди так же обеспечивают существование скриптухи за своё счёт потому, что это позволяет им поддерживать мир С/си с классами.
Так же через это дяди эксплуатирую других дядей. Создав такую систему, что если другим дядям нужно что-то сделать для С/С++ - они вынуждены делать, в том числе, и для остального дерьма.
В данном случае меня это не особо интересует - всё это очевидно. Остановлюсь только на том, какие проблемы это производит для нас(последователей пути пацана).
Как-то многосложно разбирать это сейчас не выйдет - необходимо описать множество базовых концепций, без понимания которых понять что-то будет почти невозможно.
gcc
gcc архитектурно лучше, но только как компилятор. Во всём остальном всё те же проблемы, а семантических возможностей вообще нет.
clang
Написан как дерьмо. Это целиком и полностью дырявое, убогое дерьмо.
Если кратко, то оно содержит очень мало семантической информации. В целом оно создано только для одного - обойти его и сгенерировать ir. Обходит оно эту проблему следующим образом.
Есть некая помойка - sema. Это тысячи всяких дырявых состояний и методов, которые произвольным образом в момент парсинга инициализируются и вызываются.
После того, как ноды будут сгенерированы, шаблоны инстанцированы и прочее - sema просирается и вся информация тоже.
В ast ничего не попадаёт, кроме совсем примитивной херни.
Ему не понравилось, что для добавления новых возможностей зачастую нужно патчить саму «LLVM», а патчами к «LLVM» воспользуются авторы других фронтендов, не только «C» и «C++». Так?
Проблема «LLVM» в том, что «LLVM» это всего лишь очередное middle-end говнопредставление для компилятора для ЭВМ с фон Неймановской архитектурой (и я не могу сказать, что оно лучше абстрактного представления из того же GCC), а адепты этого «LLVM» его презентуют как некую волшебную silver bullet хуйню которая все проблемы порешает в области построения компиляторов и JIT хуйни.
Если бы это был канал (в терминах «Телеграма»), его можно было бы посмотреть в браузере (тогда бы появилась кнопка «Превью»), а это обычный акк или бот, а их «Телеграм» в браузере не показывает...
Roman in Прорыв запарты
|Serg
|https://www.linux.org.ru/forum/development/16404998?cid=16407771 Осталась ссылка на "поехавший был пойман на базовом балабольстве «сегфолт в c++»"?
что-то много докшолят в последнее время меня косплеит
t.me/proriv_zaparti2/2705
Jul 10 at 20:43
Отдельно открытый iframe с той сраницы в зависимости от PHP_REMOTE_ADDR показывает либо текст выше, либо нагло пездит
Channel with username @proriv_zaparti2 not found
Для групп это видимо сделано чтобы с одной стороны можно было что-то оттуда процитировать, сославшись на хуйню обычной ссылкой, а с другой стороны - ну надо же как-то мотивировать ставить пашкограм, и поэтому только через говнограм есть функция, чтобы удобно всё пордяд смотреть. А то вот будут всякие там халявщики просматривать группы просто так, разве это можно допускать?
#define ASSIGN_AUTO(var_name, value) typeof(value) var_name = value;
Да, эти макросы можно так переписать
, и тогда это и в Clang соберется
А вот
не очень ясно как переписать без фигурных скобок.
Вот тут разыменования нуля быть не должно
Х.з., я не думаю, что конпеляторы настолько злые, что что-то оптимизируют внутри typeof или sizeof...
З.Ы. Ну разадресуй единичку, чтобы даже формально не доебались.
То ({a;}) это lvalue и оно нормально присваивает.
Clang же не считает такую хрень валидной:
error: expression is not assignable
Чтобы свести задачу к уже решённой в этом треде.
Хотя вот кажется в MSVC препроцессор и компилятор в один бинарь запихали. Ну а что еще можно было ждать от мелкомягких?
gcc и cpp просто вызывают cc1 с разными параметрами.
Да, похоже что так. Там даже отдельная опция для раздельного препроцессирования-компилирования есть
-no-integrated-cpp
Perform preprocessing as a separate pass before compilation. By default, GCC performs preprocessing as an integrated part of input tokenization and parsing. If this option is provided, the appropriate language front end (cc1, cc1plus, or cc1obj for C, C++, and Objective-C, respectively) is instead invoked twice, once for preprocessing only and once for actual compilation of the preprocessed input. This option may be useful in conjunction with the -B or -wrapper options to specify an alternate preprocessor or perform additional processing of the program source between normal preprocessing and compilation.
Ну а что ещё можно было ждать от гнутых?
Вот тут всё описано:
https://gcc.gnu.org/onlinedocs/gccint/
.java файлы нифига не запускаются ``java``
.mc файлы нифига не запускаются ``mc``
в юниксе нет логики
Кстати, с этим связана интересная фишка, с которой я недавно столкнулась при портировании кода под линукс.
В MSVC имя функции это литерал. А в остальных конпеляторах это локальный массив, как и требует стандарт. В итоге в MSVC имя можно было конкатенировать с чем-то ещё, а в других конпеляторах -- нет.
В MSVC же выебнулись и сделали его псевдо-макросом, который раскрывается в литерал. Что, конечно, удобнее.
И это определенно добавит ебли всяким инструментам для стат. анализа, которые код после препроцессора должны хавать
Интересно, что решарпер как-то умеет макросы во время стат анализа (думмется мне, ему clang помогает)
Какая абстракция )))
но оба заменяют __LINE__
Ну тут всё по стандарту, гцц тоже заменяет лайн и файл.
Ня нужен. Это древнее нястандартное расширение. Правильные девочки-волшебняцы использнуют "__func__" (который по Стандарту ня макрос, кстати).
И что он покажет с этой вот __FUNCTION__ ": " ?
https://docs.microsoft.com/ru-ru/cpp/preprocessor/predefined-macros?view=msvc-160
__FUNCTION__ определяется как строковый литерал, содержащий недекорированное имя включающей функции. Макрос определен только в пределах функции. Макрос __FUNCTION__ не разворачивается, если используется параметр компилятора /EP или /P . Пример использования см. в разделе для макроса __FUNCDNAME__.
Про /E там ничего не сказано.
Препроцессор GCC эту __FUNCTION__ ни во что не раскрывает т.к. языка Си он не знает
Ну все чудеса завязаны на typeof. По-моему уже обсуждали это и сошлись что неплохо бы завести его в стандарт.
Который потом всякая анскильная шваль и своровала для своей дrustни.
https://t.me/tzar_blog
Можно брутом номера поста посмотреть всю ленту. Странно, похоже на канал, а кнопки «Preview channel» нет.
Кстати: «Roman». Доцента СФУ тоже зовут Романом. Это всё-таки он?
Какая секурность )))
Кстати Царь-то в последнее время не настоящий.
Он крестился, у него изменился сленг, да и прежняя искра пропала куда-то.
Отдельно открытый iframe с той сраницы в зависимости от PHP_REMOTE_ADDR показывает либо текст выше, либо нагло пездит
Channel with username @proriv_zaparti2 not found
И для разных айпишников он отдаёт разный конь-тент?
Не. Это похоже группа (кнопка View In Group ), и посты от разных авторов.
Почему они так некокококонсистентно сделали: каналы показывают в браузере целиком, а из группы только отдельные посты?
Вот это тоже есть если смотреть с адреса, который в уголке дурова не помечен как «арбузный»