И тем не менее, Python 3 продолжает развиваться и преобладает по сравнению со 2-ым (поддержка которого к слову уже закончилась вместе с началом 2020 года). По сути сейчас все оставляют как есть в угоду компания со своими древнейшими жирными монолитами кода, а из-за этого страдают новые проекты. Хотя по-хорошему в таком случае нужно просто оставаться на старой версии языка/компилятора.
если вы используете STL (то есть по сути подключаете только заголовки), то никаких проблем нет, так как программа каждый раз по сути собирается из исходников, компилятор просто инстанцирует шаблоны. Проблемы начинаются тогда, когда ваше приложение собирается в виде liи/dll/so файла и наружу торчит что-либо из стандартной библиотеки.
инфы действительно немного, но как минимум по этому поводу есть небольшая статья у gcc: gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
основной идеей было начиная с C++11 запретить реализовывать std::string как copy-on-write строку, а также стандартизировать SSO(small string optimization), что конечно же ломало ABI строки.
А что с json/csv/xml? Какие то идеи по поводу сариализаций в них обсуждаются, или все же стоит ждать рефлексию в C++23, а потом в лучшем случае еще года три?
1) аллокация памяти — зло. Если массив будет размером с гигабайт, получается вы ещё два выделяете? Это в принципе может как затормозить весь процесс, так и просто тут же вывалить bad_alloc
2) Данные бывают абсолютно разные, не только случайные или упорядоченные. Как поведёт себ алгоритм, если данные лежат в обратном порядке, если равны, чередуются с нулем и 1… Много вариантов, и на самом деле все это может непредсказуемо работать по времени. И если вы соревнуетесь с библиотечной версией sort, то должны и их протестировать.
Кстати у Александреску в этом году на cppcon как раз была про это лекция, как он сортировку улучшал (https://youtu.be/FJJTYQYB1JQ)
В просто случае ваш подход может и сработать, но к примеру код C++ вообще нетривиально подсветить, потому что банально трудно парсить, даже VS иногда не справляется. И выход только один — честно генерировать AST на основе полного парсинга программы с сохранением объявленных классов, функций и enum'ов с помощью подручных инструментов, а вот потом уже делать подсветку на основе этого контекста
С производительностью все не так гладко. Так как компилятора в байткод нет, то все вычисления проводятся на AST, что конечно же в разы медленней как минимум из-за разрозненности данных в памяти. Сам Jason говорит по этому поводу тут: discourse.chaiscript.com/t/moving-to-a-bytecode-representation/186/3
Да, в принципе я с вамм согласен. Видимо это опять же сделано для совместимости с C++, так как объявленные классы в скрипте фиксированным типом не обладают и соответственно прямого доступа из вызывающего кода к ним нет. Поведение объектов похоже на dynamic в шарпе
Вы просто перечислили парсер-генераторы, из которых шарп поддерживает только antlr. Но все они генерируют AST, дальше все равно придется с ним работать в коде. Да и в принципе, судя по всему часть с парсингом опущена в статье, потому что сразу идёт работа с деревом выражений
меня очень прикалывает, как VS подсказывает названия для массивов и списков. То есть пишешь условный List и в подсказках к имени сразу users и RegisteredUsers. Особенно удивило, когда для Person[] он предложил именно people. Мелочь, а приятно:)
Посыл правильный, но блин… Задача на динамику через матрицы не самый лучший пример. Можно было бы просто взять область геймдева, где какие-то математические вычисления на каждом углу — там тоже будет векторная алгебра, матрицы. Да собственно вся компьютерная графика на математике построена.
Если искать что-то потяжелее, то взять можно физические симуляции. Вот там начинается жуть в виде решения диффуров и ангема, и вряд ли со школьными знаниями получится такое вывезти
Есть планы написать про SPH для 3D случая, однако самый простой способ — взять текущий код и расширить его для трёхмерного случая, код kernel.cu практически не поменяется. Также у Nvidia есть соответствующая статья: https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch30.html
На точность больше всего влияет количество итераций для давления и вязкости. Но при их увеличении линейно падает скорость работы алгоритма. Размер сетки также влияет, так что тут нужен некий баланс между производительностью, качеством и красотой. В оригинальном варианте все вычисления проводятся на шейдерах, и это бесспорно эффективней, учитывая что у Cuda если API для работы с OpenGL. Но для статьи решил выбрать более простой и понятный способ
основной идеей было начиная с C++11 запретить реализовывать std::string как copy-on-write строку, а также стандартизировать SSO(small string optimization), что конечно же ломало ABI строки.
А что с json/csv/xml? Какие то идеи по поводу сариализаций в них обсуждаются, или все же стоит ждать рефлексию в C++23, а потом в лучшем случае еще года три?
1) аллокация памяти — зло. Если массив будет размером с гигабайт, получается вы ещё два выделяете? Это в принципе может как затормозить весь процесс, так и просто тут же вывалить bad_alloc
2) Данные бывают абсолютно разные, не только случайные или упорядоченные. Как поведёт себ алгоритм, если данные лежат в обратном порядке, если равны, чередуются с нулем и 1… Много вариантов, и на самом деле все это может непредсказуемо работать по времени. И если вы соревнуетесь с библиотечной версией sort, то должны и их протестировать.
Кстати у Александреску в этом году на cppcon как раз была про это лекция, как он сортировку улучшал (https://youtu.be/FJJTYQYB1JQ)
В просто случае ваш подход может и сработать, но к примеру код C++ вообще нетривиально подсветить, потому что банально трудно парсить, даже VS иногда не справляется. И выход только один — честно генерировать AST на основе полного парсинга программы с сохранением объявленных классов, функций и enum'ов с помощью подручных инструментов, а вот потом уже делать подсветку на основе этого контекста
Тащить js ну такое… При этом мы теряем адекватную типизацию. Тогда уж питон взять проще
А как же их надо писать, если не секрет?
меня очень прикалывает, как VS подсказывает названия для массивов и списков. То есть пишешь условный List и в подсказках к имени сразу users и RegisteredUsers. Особенно удивило, когда для Person[] он предложил именно people. Мелочь, а приятно:)
Посыл правильный, но блин… Задача на динамику через матрицы не самый лучший пример. Можно было бы просто взять область геймдева, где какие-то математические вычисления на каждом углу — там тоже будет векторная алгебра, матрицы. Да собственно вся компьютерная графика на математике построена.
Если искать что-то потяжелее, то взять можно физические симуляции. Вот там начинается жуть в виде решения диффуров и ангема, и вряд ли со школьными знаниями получится такое вывезти
А когда статьи на Хабре можно будет не читать?)
Есть планы написать про SPH для 3D случая, однако самый простой способ — взять текущий код и расширить его для трёхмерного случая, код kernel.cu практически не поменяется. Также у Nvidia есть соответствующая статья: https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch30.html