Это один в один обход в ширину. Разница лишь в том, что при обходе в ширину клетки, которые нужно обойти, ставятся в одну очередь, а тут они "разделены на эпохи". Те же яйца только в профиль
Я не автор начального комента, но попробую ответить. Ваша статья техническая. Обычно стрельнувшие технические статьи содержат или крутую идею, или реализацию чего-то по-настоящему сложного. Эта не содержит сложной идеи и при этом является комбинацией работы с PowerShell и git. Инструкции к каждому из этих инструментов легко гуглятся, как и готовые примеры к ним. Формально в вашей статье ничего неправильного нет, но зачем она, если такой скрипт собирается просто гуглингом? Имхо, это не уровень хабра
Можно несколько констант задавать одновременно и таким образом сжать код ещё сильнее.
В bfc простор для оптимизаций просто огромный, но я все нетривиальные оптимизации отметаю в угоду универсальности кода, так как хочу замахнуться ещё на уровень выше
Круть! Написал похожий оптимизатор на хаскеле, добавил схлопывание плюсов с минусами, немного модифицировал кодогенераторы, чтобы программы были подогнаны под оптимизатор и скомпилированный код стал в разы короче
Кстати, весь исходный код можно было бы хорошо сжать. Кажесь, там большую часть кода занимают смещения по регистрам. У меня их всего 32, но можно было бы обойтись восьмью: четыре общего назначения, четыре временных. Это бы сделало код в несколько раз короче
Идея с расширяемой структурой очень годная. Такой подход действительно сильно мощнее/удобнее того, что сделал я, но реализацию, кажется, можно сделать немного проще.
По стандарту можно кастовать указатель на структуру и на её первый элемент. Я думаю, наследники обязаны иметь функциональность базового класса, и тогда tag не нужен. Просто во всех наследников положим первым полем callback_base типа callback_functor_t. Отпадает необходимость и в макросе, так как теперь перегонять в начальный тип можно напрямую
Про локи и обработку ошибок справедливо, но не хотелось сильно загромождать код. Как-никак это больше "смотрите как могу", чем готовый продукт)
Можно сделать как в плюсах, но я бы для этого воспользовался иной конструкцией. Механизм callback-ов, как мне кажется, должен позволять навесить их несколько штук, а resource может использоваться для проделывания всяких штук за пределами объекта, например, уведомить какой-то кусок кода, что данного объекта больше не существует или послать что-то в сокет.
В общем, если делать только деструкторы, то разумно сделать так, но я больше думаю о callback-ах как о подписке на событие удаления объекта
Начиная с C11 есть ключевое слово _Alignas и в хедере stdalign.h определён макрос alignas, который в него раскрывается. Но тут я тут пользуюсь самым новым стандартом C23 (он же c2x), в котором alignas сделали ключевым словом (и добавили nullptr), а для старых версий просто добавляете флаг -DOLD, который превращает это в валидный C11 код. Попробуйте скомпилировать, на gcc-10 и clang-11 точно работает
О, вместе со значением возвращать новое состояние генератора. Встречал такое в хаскеле, но тут не додумался использовать. Изящное решение, надо будет попробовать
Возможно, так даже проще будет добавить рекуррентные генераторы
Я с рестартами пока не разобрался, но из того, что слышал: они, вроде, позволяют продолжить исполнение там, где оно прервалось. На их основе нельзя что-то типа yield сделать?
Или на каком-то хитром замыкании, которое позволит извне вернуться и продолжить исполнять там, где закончили
Common Lisp мультипарадигменный. В нём нет нет необходимых вещей, чтобы называться сильным функциональным ЯПом (контроль эффектов, иммутабельность, сильная система типов). А слабыми фунциональными (есть функции как объекты первого порядка) являются почти все современные языки
Научить генерировать на формально верифицируемых языках (agda, idris). Тогда другая машина сможет убедиться, что сгенерированная программа корректная, а человек просто проверит, что соотношения выраженные на типах соответствуют ТЗ
Позволю себе не согласиться. Имхо, книга Уилл Курт -- Программируй на хаскель рассказывает про хаскель лучше чем эта, хоть и не так подробно
Это один в один обход в ширину. Разница лишь в том, что при обходе в ширину клетки, которые нужно обойти, ставятся в одну очередь, а тут они "разделены на эпохи". Те же яйца только в профиль
Я не автор начального комента, но попробую ответить. Ваша статья техническая. Обычно стрельнувшие технические статьи содержат или крутую идею, или реализацию чего-то по-настоящему сложного. Эта не содержит сложной идеи и при этом является комбинацией работы с PowerShell и git. Инструкции к каждому из этих инструментов легко гуглятся, как и готовые примеры к ним. Формально в вашей статье ничего неправильного нет, но зачем она, если такой скрипт собирается просто гуглингом? Имхо, это не уровень хабра
P.S. Примеры крутых статей:
https://habr.com/ru/articles/590469/
https://habr.com/ru/articles/463957/
https://habr.com/ru/articles/101810/
Прочёл на одном дыхании. Автор крут, хабр торт!
Жду продолжения
Можно несколько констант задавать одновременно и таким образом сжать код ещё сильнее.
В bfc простор для оптимизаций просто огромный, но я все нетривиальные оптимизации отметаю в угоду универсальности кода, так как хочу замахнуться ещё на уровень выше
[-]++...+. В си это эквивалентноКруть! Написал похожий оптимизатор на хаскеле, добавил схлопывание плюсов с минусами, немного модифицировал кодогенераторы, чтобы программы были подогнаны под оптимизатор и скомпилированный код стал в разы короче
Кстати, весь исходный код можно было бы хорошо сжать. Кажесь, там большую часть кода занимают смещения по регистрам. У меня их всего 32, но можно было бы обойтись восьмью: четыре общего назначения, четыре временных. Это бы сделало код в несколько раз короче
В forth аналогичная конструкция это 1 2 3 4 5 6 + + + + +
В случае, когда у водорода заменяют протон на позитрон, конечно, в некотором смысле вырожденный, но принципиально это уже возможно
https://ru.m.wikipedia.org/wiki/Позитроний
Ну так не интересно!
https://youtube.com/watch?v=XHosLhPEN3k
Идея с расширяемой структурой очень годная. Такой подход действительно сильно мощнее/удобнее того, что сделал я, но реализацию, кажется, можно сделать немного проще.
По стандарту можно кастовать указатель на структуру и на её первый элемент. Я думаю, наследники обязаны иметь функциональность базового класса, и тогда
tagне нужен. Просто во всех наследников положим первым полемcallback_baseтипаcallback_functor_t. Отпадает необходимость и в макросе, так как теперь перегонять в начальный тип можно напрямуюdel
Про локи и обработку ошибок справедливо, но не хотелось сильно загромождать код. Как-никак это больше "смотрите как могу", чем готовый продукт)
Можно сделать как в плюсах, но я бы для этого воспользовался иной конструкцией. Механизм callback-ов, как мне кажется, должен позволять навесить их несколько штук, а resource может использоваться для проделывания всяких штук за пределами объекта, например, уведомить какой-то кусок кода, что данного объекта больше не существует или послать что-то в сокет.
В общем, если делать только деструкторы, то разумно сделать так, но я больше думаю о callback-ах как о подписке на событие удаления объекта
Начиная с C11 есть ключевое слово _Alignas и в хедере stdalign.h определён макрос alignas, который в него раскрывается. Но тут я тут пользуюсь самым новым стандартом C23 (он же c2x), в котором alignas сделали ключевым словом (и добавили nullptr), а для старых версий просто добавляете флаг -DOLD, который превращает это в валидный C11 код. Попробуйте скомпилировать, на gcc-10 и clang-11 точно работает
Сарказм же толстейший, разве нет?
О, вместе со значением возвращать новое состояние генератора. Встречал такое в хаскеле, но тут не додумался использовать. Изящное решение, надо будет попробовать
Возможно, так даже проще будет добавить рекуррентные генераторы
Я с рестартами пока не разобрался, но из того, что слышал: они, вроде, позволяют продолжить исполнение там, где оно прервалось. На их основе нельзя что-то типа yield сделать?
Или на каком-то хитром замыкании, которое позволит извне вернуться и продолжить исполнять там, где закончили
Common Lisp мультипарадигменный. В нём нет нет необходимых вещей, чтобы называться сильным функциональным ЯПом (контроль эффектов, иммутабельность, сильная система типов). А слабыми фунциональными (есть функции как объекты первого порядка) являются почти все современные языки
Научить генерировать на формально верифицируемых языках (agda, idris). Тогда другая машина сможет убедиться, что сгенерированная программа корректная, а человек просто проверит, что соотношения выраженные на типах соответствуют ТЗ