Видимо, только в школе? И на сборы вы никакие не ездили?
В школе у про программирование знал ровно один человек, да и тот на бэйсике. Офлайн был на паре олимпиад, но одна какая-то мелкая местная и вообще не помню про что было, вторая - областная олимпиада среди околопрофильных СУЗов. От нашего учебного заведения просто пару человек участников было, все зачеты были персональными и всего на событие прибыло человек 15-20 может быть. Никаких сборов не было как сущности. Просто сразу везли на событие. И такой формат обычно проще и дешевле хостить и повторять.
Ну и ещё раз - на ICPC свет клином не сошёлся и его правила не единственный формат проведения олимпиад по программированию. И большинство подобных событий нацеливается именно на персональное ранжирование, а не командный зачёт.
Тем не менее, если заниматья этим серьезно, то придется разбираться в чужом коде, читать разборы и общатся с людьми.
Несомненно, что придётся читать и писать много кода. А с людьми это как повезёт. Как и с обычным программированием. Это не что-то уникальное только для спортивного программирования.
По моему опыту даже последние интроверты и откровенные аутисты как раз с радостью говорят о том, что им интересно.
Не могу сказать, что встречал много подобных людей живьем, не говоря уже о проведении каких-либо интервью с оными - я же правильно понимаю что речь изначально шла о техническом интервью при приеме?
даже перепутав знак или ошибившись в арифметике, нарушить какой-то этикет.
зато можно назвать делитель делимым и спутать интервьювера делением на ноль невпопад. Интервью для многих довольно стрессовое событие и невротиков в мире тоже немало.
популярных соревнованиях
ключевое слово - популярных. есть ещё непопулярные и люди там тоже участвуют. те же школьные межклассы, например.
но командная работа там не такое уж и исключение.
я не утверждал о некой исключительности командной работы на таких событиях - просто их меньше по сравнению с общим количеством событий.
Сразу видно, человек с олимпиадным програмимрованием не знаком.
ну, так-то участник как офлайн так и онлайн соревнований. в одной региональной даже в своё время даже второе место занял.
На олимпиадах их обычно нельзя использовать.
поэтому и написал "вместо". обычно явных запретов на это нет, но проблема всплывает чаще всего из-за необходимости знать архитектуру машины, которая проверяет решения и необходимости добавить что-нибудь к флагам сборки. в С++ 26 simd появился в стандартной библиотеке и если этот язык будет разрешен в конкретных контестах, то по каким религиозным соображением это стоит запрещать? Та же история с asm вставками.
Самое пристижное и популярное соревнование - ICPC - командное.
Ну так на нём свет клином не сошёлся. CodeForces и LeetCode проводят постоянные периодические контесты - туда командой не воткнуться обычно. Некоторые олимпиады используют формат командных очков, когда все члены команды решают все задачи и командные очки за отправленные решения суммируются в командный зачёт для глобального ранжирования команд. Так что большинство олимпиадных соревнований - персональные, а формат командных хакатонов скорее исключение для более глобальных соревнований.
объяснять свое решение и понимать чужие
это не сказать чтобы титаническая задача. в командном зачёте и без этого обычно брейнсторм случается о подходах, если коммуникация разрешается.
Проводя интервью видел много людей, которые вообще не в состоянии сформулировать, что они хотят сделать и как будут решать задачу
Если человек никогда не участвовал в командных тренировках, то откуда браться навыку коммуницирования? Многие могут решать задачи только методом проб и ошибок, а не каким-то глубоким планированием, большинство не способны держать в голове всю цепочку взаимосвязей, поэтому начинают делать наброски и решают вопросы по мере их поступления, кто-то просто с социальной тревожностью и попытки начать объяснять загоняют их в паническую петлю из-за страха сказать что-нибудь "не то" - возможности и бэкграунд у людей разные, Спортивное программирование в этом плане ортогонально конретно этой проблеме с коммуницированием.
Спортивное программирование имеет обычно больше ограничений, чем бизнес программирование, и эти ограничения могут привносить отпечаток - будь то выжимание байтов с использованием нечитаемых техник вместо вызова каких-нибудь simd интрисиков, написанием кастомных имплементаций того что и без этого есть в стандартной библиотеке, как результат - нечитаемый код и непрагматичный NIH-синдром. Ну и командная работа в спортивном программировании - это скорее исключение.
Спортивное программирование это скорее индикатор, чтобы показать человеку чего тот не знает и каким подходам можно научиться.
если бы мы могли инстанцировать шаблоны не шаблонным кодом
ну вот собственно про подобное инстанцирование и говорил, да. Но да, ручками разворачивать боль.
парсинг вручную делают на С++
там ещё куча арен для более линейных аллокаций и какие-то кастомные рекурсивные мьютексы и система асинхронных тасок.
макросами в заголовочнике
там ещё и интернирование через #include "file.cpp". Очень много разных нестандартных приколюх, вписывающихся в идею языка - делать проще, а не заумнее.
Если под eval подразумевается compile time исполнение то видимо Билл не осилил его доставить и может быть что-то будет к релизу 1.0 в январе следующего года. У Jai - языке побратиме - точно есть довольно мощная система макросов, которая позволяет запускать почти произвольный код в CT, но у него компилятор пока в закрытой бете.
вот это я опять не понимаю что вы тут имеете ввиду: какой ещё аналогичный код?
я похоже не правильно понял назначение того кода. вопрос снят.
считаю что это только замедлит компиляцию, т.к компилятору придётся парсить больше текста
когда код линейный и не имеет скрытой дополнительной семантики (ODR check, SFINAE, conсepts, type traits, inhetance), то и парсинг такого кода становится максимально линейным и сокращается количество проходов. Паскаль, Go, V, Odin и Jai - по этой причине имеют безумно быстрые компиляторы, которые начинают страдать в основном только на проходах оптимизации. Odin и Jai способны скомпилировать полмиллиона строк кода за секунду на одном ядре - без кэширования артефактов, без инкрементальных сборок. Так что нет, больше простого плоского кода не добавляет проблем компилятору и позволяет агрессивно распараллеливать компиляцию. Любой полиморфизм и рефлексия в языках заставляют компиляторы делать крюк и именно подобный код замедляет компиляцию, по крайней мере на этапе парсинга. Похожая проблема возникает кстати и на этапе линковки, когда заглушки вызовов начинают прибивать к реальным вызовам функций.
наоборот же должно быть? когда это от инстанцирования шаблонов скорость компиляции росла?
скорость компиляции растет тем больше чем меньше компилятор занимается деятельностью. инстанциорование шаблонов (aka мономорфизация) и проверка всяких ODR в большинстве языков реализующих подобные механизмы шаблонов довольно медленные - рекурсивное инстанцировние, поиск шаблонов, подстановка ссылок на инстанции шаблонных функций или инлайнинг, проверка коллизий, всякие проверки границ типов через те же концепты - всё это довольно не быстрая история и обычно требующая нескольких дополнительных проходов по AST. Поэтому если вы самостоятельно проведёте подобную мономорфизацию, то компиляция в теории может ускориться при определённых сценариях - компилятору не нужно будет гадать какую функцию позвать и останется только прокинуть нужные аргументы.
тут где-то путаница, что вы подразумеваете под генерацией?
Насколько я понял вы берёте некоторый код, прогоняете его сквозь свой фронт и не выходе получаете некоторое собственное представление AST, которое можно скормить дальше по пайплайну в обычный компилятор (пока не напишите свой). Вот этот шаг от обработки через ваш фронт и до этапа когда оно попадает в компилятор я и назвал генерацией. Сравнивать предлагал с аналогичным кодом, который бы писался на плюсах ручками.
Синтаксис плюсов тянет с собой очень много семантики, DFA разве, что на токенизацию можно написать, но она не сказать чтобы сильно тормозная и в том виде, что есть. Парсинг и построение AST - вот где медленная собака зарыта. Но эти шаги не выразить в DFA.
Так оно и не контейнерное же. Встаёт как обычное приложение, просто зависимости с собой таскает и не требует ни подключения дополнительных реестров, ни сети. Это не изоляция как у flatpack, это что-то вроде самораспаковывающегося архива.
не вижу ничего про модули (module, import, export), ничего связанного с корутинами (co_await, co_yield etc), consteval упомянут в скрипте в часть 1, но похоже тоже нигде больше не участвует. constinit туда же, всякие [[аттрибуты]] не замечены, explicit(bool) не замечен, синтаксис рефлексии и синтаксис контрактов - тоже не видны.
не очень понятно зачем вы целое одно предложение под спойлер спрятали. У вас в том файле кодировка сползла и похоже часть текста в windows-1251.
Для сравнения: на моей машине cl.exe компилирует мой код со скоростью ~70KB/s
Это несколько бессмысленное сравнение. Проинстанцируйте в сгенерированном коде ещё и шаблоны и скорость компиляции вырастет ещё больше. Умудритесь вычислить лексически все constexpr/consteval - получите ещё плюс. Ну и можно поэкономить на спичках убрав всякие public: public:. А вообще стоило бы замерить сколько времени занимает генерация и сравнить с компиляцие того же файла без генерации.
почему vars, а не env? кушает ли оно перегрузки из внешнего env? есть ли возможность держать несколько наборов под разные компиляторы? Работает ли оно в CI/CD с матрицами значений? есть ли дефолтные значения чтобы не копипастить как в вашем примере с run_linux? Сравнивали с каким-нибудь bazel?
Учитывая, что у вас требуется подключение к внешней сети оно не очень закрытое получается. Не думали попробовать собрать AppImage вместо этого? Один файл установки можно хоть на флешку закинуть и ставить на произвольную машину без сети.
Предложил бы поддержать gcov как один из наиболее распространённых и имеющий поддержку для многих языков, в частности C, C++ и Python. У него вроде есть какая-то совместимость с JUnit в качестве выходного формата, но прикрутить JUnit в обратную сторону для этих языков проблемнее.
Как-то странно себя сон ведёт - плохо восполняется, быстро тратится.
У довольного цыплёнка над головой вист какой-то непонятный хвостик слева над головой
Скрытый текст
Ещё бы предложил сделать так чтобы панель с ачивками была также рядом на странице, а не требовала необходимость крутить страницу, а раздел с помощью вообще спрятать под какую-нибудь кнопку.
Ну, а новых видов придумать вроде не сложно - бычок, лама, капибара, аксолотль, коза, слоник, бабуин, ёжик, крош, совунья, попугай и тп.
Собственно первое, что пришло в голову. Подготовить некоторый случайный набор из 100 уникальных имён и просто гонять перестановки. Для полового баланса можно делать то же самое но дважды по 50. При таких размерах сета количество дублей и повторов имён из оригинала сокращается на порядок.
Размерность это все же про то как измерять растояния - устанавливать размер, а измерения про по скольки осям это можно делать - измерять. Семантически вроде достаточно корректно.
Ну, а с парачастицами к вам вопрос - как бы вы их назвали в таком случае? квази уже заняты.
noexcept по-большому счёту несёт справочных характер для компилятора. Если бы там гнались за перформансом, то по-хорошему стоило бы указать, но статья не про это и по большому счёту принципиальной разницы это не добавляет.
Цепочку лямбд неудобно отлаживать, и выглядит такой код не очевидно, и места они занимают много.
Ну это несколько странная телега. То что вы можете писать лямбды не требует от вас это делать - пишите обычные функции. Ну и отлаживать код с исключениями не сказать чтобы сильно проще, особенно в многопотоке.
В этом смысле сишники давно изобрели errno
оно на маленьком коде может и хорошо, но иметь некоторое глобальное состояние да ещё и в многопотоке, довольно заметный минус для оптимизатора - появляются неоптимизируемые индирекции. Ну и как в си гадать от кого из стека прилетело -1 вместо того чтобы явно видеть DbError::AccessDenied имеет свои следствия для безопасности финального кода.
В школе у про программирование знал ровно один человек, да и тот на бэйсике. Офлайн был на паре олимпиад, но одна какая-то мелкая местная и вообще не помню про что было, вторая - областная олимпиада среди околопрофильных СУЗов. От нашего учебного заведения просто пару человек участников было, все зачеты были персональными и всего на событие прибыло человек 15-20 может быть. Никаких сборов не было как сущности. Просто сразу везли на событие. И такой формат обычно проще и дешевле хостить и повторять.
Ну и ещё раз - на ICPC свет клином не сошёлся и его правила не единственный формат проведения олимпиад по программированию. И большинство подобных событий нацеливается именно на персональное ранжирование, а не командный зачёт.
Несомненно, что придётся читать и писать много кода. А с людьми это как повезёт. Как и с обычным программированием. Это не что-то уникальное только для спортивного программирования.
Не могу сказать, что встречал много подобных людей живьем, не говоря уже о проведении каких-либо интервью с оными - я же правильно понимаю что речь изначально шла о техническом интервью при приеме?
зато можно назвать делитель делимым и спутать интервьювера делением на ноль невпопад. Интервью для многих довольно стрессовое событие и невротиков в мире тоже немало.
ключевое слово - популярных. есть ещё непопулярные и люди там тоже участвуют. те же школьные межклассы, например.
я не утверждал о некой исключительности командной работы на таких событиях - просто их меньше по сравнению с общим количеством событий.
ну, так-то участник как офлайн так и онлайн соревнований. в одной региональной даже в своё время даже второе место занял.
поэтому и написал "вместо". обычно явных запретов на это нет, но проблема всплывает чаще всего из-за необходимости знать архитектуру машины, которая проверяет решения и необходимости добавить что-нибудь к флагам сборки. в С++ 26 simd появился в стандартной библиотеке и если этот язык будет разрешен в конкретных контестах, то по каким религиозным соображением это стоит запрещать? Та же история с asm вставками.
Ну так на нём свет клином не сошёлся. CodeForces и LeetCode проводят постоянные периодические контесты - туда командой не воткнуться обычно. Некоторые олимпиады используют формат командных очков, когда все члены команды решают все задачи и командные очки за отправленные решения суммируются в командный зачёт для глобального ранжирования команд. Так что большинство олимпиадных соревнований - персональные, а формат командных хакатонов скорее исключение для более глобальных соревнований.
это не сказать чтобы титаническая задача. в командном зачёте и без этого обычно брейнсторм случается о подходах, если коммуникация разрешается.
Если человек никогда не участвовал в командных тренировках, то откуда браться навыку коммуницирования? Многие могут решать задачи только методом проб и ошибок, а не каким-то глубоким планированием, большинство не способны держать в голове всю цепочку взаимосвязей, поэтому начинают делать наброски и решают вопросы по мере их поступления, кто-то просто с социальной тревожностью и попытки начать объяснять загоняют их в паническую петлю из-за страха сказать что-нибудь "не то" - возможности и бэкграунд у людей разные, Спортивное программирование в этом плане ортогонально конретно этой проблеме с коммуницированием.
Спортивное программирование имеет обычно больше ограничений, чем бизнес программирование, и эти ограничения могут привносить отпечаток - будь то выжимание байтов с использованием нечитаемых техник вместо вызова каких-нибудь simd интрисиков, написанием кастомных имплементаций того что и без этого есть в стандартной библиотеке, как результат - нечитаемый код и непрагматичный NIH-синдром. Ну и командная работа в спортивном программировании - это скорее исключение.
Спортивное программирование это скорее индикатор, чтобы показать человеку чего тот не знает и каким подходам можно научиться.
ну вот собственно про подобное инстанцирование и говорил, да. Но да, ручками разворачивать боль.
там ещё куча арен для более линейных аллокаций и какие-то кастомные рекурсивные мьютексы и система асинхронных тасок.
там ещё и интернирование через
#include "file.cpp". Очень много разных нестандартных приколюх, вписывающихся в идею языка - делать проще, а не заумнее.Если под eval подразумевается compile time исполнение то видимо Билл не осилил его доставить и может быть что-то будет к релизу 1.0 в январе следующего года. У Jai - языке побратиме - точно есть довольно мощная система макросов, которая позволяет запускать почти произвольный код в CT, но у него компилятор пока в закрытой бете.
я похоже не правильно понял назначение того кода. вопрос снят.
когда код линейный и не имеет скрытой дополнительной семантики (ODR check, SFINAE, conсepts, type traits, inhetance), то и парсинг такого кода становится максимально линейным и сокращается количество проходов. Паскаль, Go, V, Odin и Jai - по этой причине имеют безумно быстрые компиляторы, которые начинают страдать в основном только на проходах оптимизации. Odin и Jai способны скомпилировать полмиллиона строк кода за секунду на одном ядре - без кэширования артефактов, без инкрементальных сборок. Так что нет, больше простого плоского кода не добавляет проблем компилятору и позволяет агрессивно распараллеливать компиляцию. Любой полиморфизм и рефлексия в языках заставляют компиляторы делать крюк и именно подобный код замедляет компиляцию, по крайней мере на этапе парсинга. Похожая проблема возникает кстати и на этапе линковки, когда заглушки вызовов начинают прибивать к реальным вызовам функций.
скорость компиляции растет тем больше чем меньше компилятор занимается деятельностью. инстанциорование шаблонов (aka мономорфизация) и проверка всяких ODR в большинстве языков реализующих подобные механизмы шаблонов довольно медленные - рекурсивное инстанцировние, поиск шаблонов, подстановка ссылок на инстанции шаблонных функций или инлайнинг, проверка коллизий, всякие проверки границ типов через те же концепты - всё это довольно не быстрая история и обычно требующая нескольких дополнительных проходов по AST. Поэтому если вы самостоятельно проведёте подобную мономорфизацию, то компиляция в теории может ускориться при определённых сценариях - компилятору не нужно будет гадать какую функцию позвать и останется только прокинуть нужные аргументы.
Насколько я понял вы берёте некоторый код, прогоняете его сквозь свой фронт и не выходе получаете некоторое собственное представление AST, которое можно скормить дальше по пайплайну в обычный компилятор (пока не напишите свой). Вот этот шаг от обработки через ваш фронт и до этапа когда оно попадает в компилятор я и назвал генерацией. Сравнивать предлагал с аналогичным кодом, который бы писался на плюсах ручками.
Синтаксис плюсов тянет с собой очень много семантики, DFA разве, что на токенизацию можно написать, но она не сказать чтобы сильно тормозная и в том виде, что есть. Парсинг и построение AST - вот где медленная собака зарыта. Но эти шаги не выразить в DFA.
Так оно и не контейнерное же. Встаёт как обычное приложение, просто зависимости с собой таскает и не требует ни подключения дополнительных реестров, ни сети. Это не изоляция как у flatpack, это что-то вроде самораспаковывающегося архива.
не вижу ничего про модули (module, import, export), ничего связанного с корутинами (co_await, co_yield etc),
constevalупомянут в скрипте в часть 1, но похоже тоже нигде больше не участвует. constinit туда же, всякие [[аттрибуты]] не замечены,explicit(bool)не замечен, синтаксис рефлексии и синтаксис контрактов - тоже не видны.не очень понятно зачем вы целое одно предложение под спойлер спрятали. У вас в том файле кодировка сползла и похоже часть текста в windows-1251.
Это несколько бессмысленное сравнение. Проинстанцируйте в сгенерированном коде ещё и шаблоны и скорость компиляции вырастет ещё больше. Умудритесь вычислить лексически все constexpr/consteval - получите ещё плюс. Ну и можно поэкономить на спичках убрав всякие public: public:. А вообще стоило бы замерить сколько времени занимает генерация и сравнить с компиляцие того же файла без генерации.
почему vars, а не env? кушает ли оно перегрузки из внешнего env? есть ли возможность держать несколько наборов под разные компиляторы? Работает ли оно в CI/CD с матрицами значений? есть ли дефолтные значения чтобы не копипастить как в вашем примере с run_linux? Сравнивали с каким-нибудь bazel?
Учитывая, что у вас требуется подключение к внешней сети оно не очень закрытое получается. Не думали попробовать собрать AppImage вместо этого? Один файл установки можно хоть на флешку закинуть и ставить на произвольную машину без сети.
Предложил бы поддержать gcov как один из наиболее распространённых и имеющий поддержку для многих языков, в частности C, C++ и Python. У него вроде есть какая-то совместимость с JUnit в качестве выходного формата, но прикрутить JUnit в обратную сторону для этих языков проблемнее.
Как-то странно себя сон ведёт - плохо восполняется, быстро тратится.
У довольного цыплёнка над головой вист какой-то непонятный хвостик слева над головой
Скрытый текст
Ещё бы предложил сделать так чтобы панель с ачивками была также рядом на странице, а не требовала необходимость крутить страницу, а раздел с помощью вообще спрятать под какую-нибудь кнопку.
Ну, а новых видов придумать вроде не сложно - бычок, лама, капибара, аксолотль, коза, слоник, бабуин, ёжик,
крош, совунья, попугай и тп.Собственно первое, что пришло в голову. Подготовить некоторый случайный набор из 100 уникальных имён и просто гонять перестановки. Для полового баланса можно делать то же самое но дважды по 50. При таких размерах сета количество дублей и повторов имён из оригинала сокращается на порядок.
Размерность это все же про то как измерять растояния - устанавливать размер, а измерения про по скольки осям это можно делать - измерять. Семантически вроде достаточно корректно.
Ну, а с парачастицами к вам вопрос - как бы вы их назвали в таком случае? квази уже заняты.
noexcept по-большому счёту несёт справочных характер для компилятора. Если бы там гнались за перформансом, то по-хорошему стоило бы указать, но статья не про это и по большому счёту принципиальной разницы это не добавляет.
Scratch
Ну это несколько странная телега. То что вы можете писать лямбды не требует от вас это делать - пишите обычные функции. Ну и отлаживать код с исключениями не сказать чтобы сильно проще, особенно в многопотоке.
оно на маленьком коде может и хорошо, но иметь некоторое глобальное состояние да ещё и в многопотоке, довольно заметный минус для оптимизатора - появляются неоптимизируемые индирекции. Ну и как в си гадать от кого из стека прилетело -1 вместо того чтобы явно видеть DbError::AccessDenied имеет свои следствия для безопасности финального кода.
Это всегда один единственный yaml файл или как на github есть возможность завести какую-нибудь папочку .gitflic и складировать CI/CD конвееры туда?
Планируется ли что-то кроме JUnit для сбора покрытия?
Собственно вопрос - а почему не использовать nginx? На конфиг кажется ложится, только описание будет не таким лаконичным.