Полезная вещь на самом деле. Сам лично пользуюсь похожей "однокнопочной" программой на телефоне (cxxdroid), когда нет доступа к компу или лень. Но под десктоп такого и правда иногда не хватает.
Мой максимум бесполезных действий, если надо что-то быстро проверить: новая вкладка в терминале, в отдельном заранее готовом проекте для тестов, и уже там собираю свой один несчастный исходник.
Чтож, я не смог найти такого ключа и теперь не уверен в поддержке такого функционала в используемых мной средствах.
В связи с этим могу предложить несколько альтернатив:
Использовать наработки в существующем скрипте (обнаружение аргументов функций не в столбик) и приспособление вашего кода к форматированию. (Сделайте свой собственный форматировщик).
Поиск тех решений, которые обладают функционалом разбиения параметров в столбик, но таких, насколько понимаю, в широком доступе нет, либо способ достижения нужного эффекта слишком сложен.
Правка чужих открытых для модификации решений либо использование уже правленых решений (добавить функционал в тот же clang-format или найти его ветку/форк с работающей опцией).
(Самый неподходящий) Уточнение/пересмотр требований. В комментариях не нуждается.
Опция называется "BinPackParameters", но поддерживает только true/false. При этом clang-format сам в процессе выбирает, оставить всё на одной строке или разбить. Разбивает только если они все не вмещаются на одну линию, наверное.
Собственно, поэтому я больше не использую clang-format — нечеткий форматтер мне не подошёл, а пытаться найти комбинации из 3-5 опций чтобы добиться нужного эффекта или узнать, что такого ещё не сделали, не хочется.
Прошёлся ещё раз по списку и не заметил того, что показалось мне странным при первом прочтении.
Могу разве что выделить требования к стилю кода (как и написано, code style) по типу "без символов табуляции", "длина ≤80 символов", "параметры функций в столбик". Такие решаются форматировщиком.
И ещё одно — про закомментированный код, но, наверное, это уже у меня какие-то проблемы с оставлением ненужного функционала.
При наличии у вас исходников скрипта-надзорщика можно и сам скрипт потыкать: 1) чтоб не вылетал, 2) чтоб писал куда нужно системе сборки, 3) чтоб писал только нужное.
Только у меня такое ощущение, что, хоть это и будет полезно в качестве распространения, но портированием Flutter'а и React чего-то должны заниматься именно разработчики этих систем, а не никак не связанные с ними Huawei?
Edit: ответ на вопрос "на чём под неё писать" — Cangjie
Так и не понял, как планировалось использовать union? Для свиззлинга ведь нужны различные места памяти в исходном объекте, а юнион такого не может делать. В Си ещё хоть какой-то type punning был, а в плюсах доступ к неактивному члену это точно UB, да ещё и делает что-то не то.
Максимум, который мне представляется юнионом, это
// C
typedef union {
struct {
int x;
int y;
};
int data[2];
} vec2;
vec2 a;
a.x;
a.y;
a.data[0];
a.data[1];
Неужели в C++ с ними придумали ещё более опасные для созерцания вещи?
Эпоха мёртвого интернета уже наступила.
И вы не узнаете, написан ли этот комментарий реальным человеком, или всё же сгенерирован нейросетью.
Звучит как комплекс неполноценности — "я не могу сравнить себя с чатдцп, что уж говорить о сравнении других с ним" :)
Невероятно точное описание ситуации...
Полезная вещь на самом деле. Сам лично пользуюсь похожей "однокнопочной" программой на телефоне (cxxdroid), когда нет доступа к компу или лень. Но под десктоп такого и правда иногда не хватает.
Мой максимум бесполезных действий, если надо что-то быстро проверить: новая вкладка в терминале, в отдельном заранее готовом проекте для тестов, и уже там собираю свой один несчастный исходник.
От которого мыши кололись, но который продолжали есть.
Чтож, я не смог найти такого ключа и теперь не уверен в поддержке такого функционала в используемых мной средствах.
В связи с этим могу предложить несколько альтернатив:
Использовать наработки в существующем скрипте (обнаружение аргументов функций не в столбик) и приспособление вашего кода к форматированию. (Сделайте свой собственный форматировщик).
Поиск тех решений, которые обладают функционалом разбиения параметров в столбик, но таких, насколько понимаю, в широком доступе нет, либо способ достижения нужного эффекта слишком сложен.
Правка чужих открытых для модификации решений либо использование уже правленых решений (добавить функционал в тот же clang-format или найти его ветку/форк с работающей опцией).
(Самый неподходящий) Уточнение/пересмотр требований. В комментариях не нуждается.
Чтож, попытался сам, получилось через раз.
Опция называется "BinPackParameters", но поддерживает только true/false. При этом clang-format сам в процессе выбирает, оставить всё на одной строке или разбить. Разбивает только если они все не вмещаются на одну линию, наверное.
Собственно, поэтому я больше не использую clang-format — нечеткий форматтер мне не подошёл, а пытаться найти комбинации из 3-5 опций чтобы добиться нужного эффекта или узнать, что такого ещё не сделали, не хочется.
Сам лично использую artistic style, но мир форматировщиков кода на C/C++ не ограничивается ни clang-format'ом, ни им.
Насколько знаю, форматировщики также есть в CLion, Visual Studio. Но это ide'шные, они внутри.
Возможно, есть и другие (гнушный какой-нибудь), но я ими не пользовался, а потому не знаю ни про их существование, ни их возможностей.
я не упоминал именно clang-format.
clang-format, насколько я понял по документации, на такое способен (https://clang.llvm.org/docs/ClangFormatStyleOptions.html#binpackparameters).
Прошёлся ещё раз по списку и не заметил того, что показалось мне странным при первом прочтении.
Могу разве что выделить требования к стилю кода (как и написано, code style) по типу "без символов табуляции", "длина ≤80 символов", "параметры функций в столбик". Такие решаются форматировщиком.
И ещё одно — про закомментированный код, но, наверное, это уже у меня какие-то проблемы с оставлением ненужного функционала.
При наличии у вас исходников скрипта-надзорщика можно и сам скрипт потыкать: 1) чтоб не вылетал, 2) чтоб писал куда нужно системе сборки, 3) чтоб писал только нужное.
За некоторые правила из набора соболезную.
Только у меня такое ощущение, что, хоть это и будет полезно в качестве распространения, но портированием Flutter'а и React чего-то должны заниматься именно разработчики этих систем, а не никак не связанные с ними Huawei?
Edit: ответ на вопрос "на чём под неё писать" — Cangjie
До прочтения статьи:
Такое вообще возможно?
День отмечается дважды, или выбирается дополнительный день. Выбор также зависит от генератора случайных чисел.
Немного не по теме, но, кажется, отчёты pvs-studio на хабре именно такие статьи из себя и представляют.
:)
https://en.cppreference.com/w/cpp/language/identifiers
в идентификаторе может быть символ из юникода, что здесь и используется (имена у определяемых функций разные)
Edit: увидел, в самом квизе всё плохо с копипастом, так что для ответа только догадаться
Так и не понял, как планировалось использовать union? Для свиззлинга ведь нужны различные места памяти в исходном объекте, а юнион такого не может делать. В Си ещё хоть какой-то type punning был, а в плюсах доступ к неактивному члену это точно UB, да ещё и делает что-то не то.
Максимум, который мне представляется юнионом, это
Неужели в C++ с ними придумали ещё более опасные для созерцания вещи?
![]()
![]()
"Swizzle в vec2/vec3/vec4 внутри C++ как в OpenGL"
Чем кодогенерация inline методов с возвратом векторов из соответсвующих полей не подошла?
Что-то типа такого:
Не знаком с плюсами даже близко, так что поправьте если где-то ошибся
В русской терминологии и математике - запятая. В английской - точка.