Рубрика «zero-allocation»

Если в современных реалиях у разработчика возникает необходимость собрать надежное решение для обработки G‑кода, он обычно смотрит в сторону готовых вариантов (GRBL/FluidNC/Linux‑CNC), либо пишет свой кастомный парсер на С/С++ или Rust и для таких проектов вариант реализации на.NET даже не рассматривается ввиду того, что платформа является управляемой и потому недостаточно надежной (заслуженно или нет — разберем далее).

Почему вообще C# и.NET?

У вас может возникнуть закономерный вопрос: зачем вообще изобретать велосипед, если традиционно для RT систем выбирают C или C++?

Для меня аргументов в пользу C# и.NET было несколько:

Читать полностью »

За свои 17+ лет в активной разработке я встречал много проблем, но одна преследовала меня постоянно: JSON. Нет, с самим форматом все ок, но вот с его чтением — не все норм.

Когда я только начинал работать с PHP, я списывал это на скриптовость языка. Отчасти из‑за этого я даже поменял стек. Но когда приходили по‑настоящему большие файлы, это всегда было больно. Иногда — очень. Был проект, где мы ждали не обработку информации бизнес‑логикой, а банального парсинга. Файлы доходили до десятков гигабайт и не всегда влезали в оперативку. Тогда я и заработал себе персональный todo — разобраться с этим раз и навсегда.

Читать полностью »

Python берут за скорость реализации. C++ - за производительность и контроль над памятью.

А Go? Go выбирают те, кто любит Go. Я один из них. Долгое время я использовал связку bufio.Scanner + ScanWords + strconv.Atoi. Но стоит в задаче смешать числа, строки или посимвольный ввод - начинаются “танцы с бубном”. В какой-то момент мне надоело, и я написал contestio. Решения оказались простыми. То чувство, когда: “Чёрт возьми! Почему мне это не пришло в голову раньше!?”

Мотивация: хочется удобно и быстро, а не выбирать


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js