Сокет - это абстракция, конечная точка соединения между сервером и клиентом, сокет представляет собой файловый дескриптор, в котором содержатся все параметры для соединения, именно через сокет и передаются многие данные.
Существуют несколько протоколов сокетов, основные из них: TCP и UDP.
Иногда в С++ не хватает каких-то фич, которые есть в других языках. Мне, например, не хватает preperties из C#. В них можно описать функции set/get, при этом работать с ними через поле класса, как с переменной.
В С++ это приходится делать через функции, что может быть громоздкои и менее читаемо:
actor.SetTransform(left.GetTransform() * right.GetTransform() * up.GetTransform());
Но хочется более простой и понятный синтаксис:
actor.transform = left.transform * righ.transform * up.transform;
Под катом я расскажу как можно в С++ обернуть set/get в переменную с минимальным размером 1 байт
При работе с C или C++ необходимо в какой-то степени разбираться в неопределённом поведении (UB): что это такое, каковы его эффекты, и как о него не споткнуться. Для простоты картины я буду в этой статье рассказывать только о C, но всё изложенное здесь также применимо и к C++, если явно не указано иное.
Думаю, вам начинают надоедать тексты про вайб-кодинг. Но не волнуйтесь, мой интерес не в том, чтобы рассказывать о новых невероятных достижениях, меняющих мир, и бла-бла-бла... Интереснее поискать места, в которых начинается сбой при генерации кода. Это позволит адаптировать работу статических анализаторов для новых задач контроля кода, который создаётся с помощью таких систем.
Ранее утро. Туман окутал горные хребты. Просыпайся, Гордон, вставай. Нам пора отправляться в сердце тьмы и освободить этот мир от лап дремлющего зла. Да, и не забудь свою монтировку.
Введение
Всё началось с комментирования статьи: «[Как я написал современный GUI для yt-dlp на Python]( https://habr.com/ru/articles/930260/)».
Программа автора мне понравилась, и я обещал ему попробовать сделать аналогичный проект на C++ / WTL.
Так вот, не прошло и полгода, как первая версия аналогичной программы уже готова. Её рабочее название – MiniDL, а исходники доступны на сайтах:
http://polezp.narod.ru/Prg/MiniDL100.zip
и
http://lecole.free.nf/Prg/MiniDL100.zip
или
https://disk.yandex.ru/d/yGQDXbkpk6LPqw
Архив содержит также скомпилированные бинарники для 32-х и 64-х разрядных, релизных версий, под Windows («MiniDL32r.exe» и «MiniDL64r.exe»).
Естественно, создать конкурентный интерфейс профессиональной библиотеке CustomTkinter, для Питона, на сверхлегком движке WTL, за обозримое время, практически невозможно. Но такая задача и не ставилась. Хотелось просто реализовать идею автора – работать с удобной графической оболочкой для консольной программы, в данном случае – внешнем загрузчике медиа-контента из Ютуба и других, поддерживаемых им сайтов.
Ради простоты, пришлось отказаться от попытки реализовать все интерфейсные плюшки автора и ограничиться минималистским вариантом. Тем более что, лично меня он вполне устраивает. Более того, поскольку я привык работать в Total Commander, то там вполне удобно использовать и консольные программы, особенно в паре с командным файлом их запуска, что позволяет перенести туда все параметры командной строки. А, в случае с загрузчиком yt-dlp.exe ситуация оказалась еще лучше, так как, он поддерживает конфигурационный файл, с мощными настройками. Если их хорошо освоить, то, в принципе, ничего больше и не надо. Ведь, эти настройки позволяют легко скачивать не только аудио и видео файлы, но и субтитры к ним и тому подобное. Также, легко и просто указать каталог загрузки, но уже в нашей программе, и не мучиться, как автор, с сохранением их на рабочий стол.
Привет Хабр! В этой статье я хотел поговорить о теме вечных конфликтов разработчиков на C++ и Rust. Стоит ли того система управления памятью в Rust или все-же это бестолковый механизм стремящийся составить конкуренцию родному методу?
Систему управления памятью я разберу, а вот выводы остаются уже за вами.
Давным-давно, когда с ездовым котом приключилась "записка шестая", а знания об аллокаторах и опыт их применения ограничивался линейным и системным, перебросили мою команду в помощь другой команде, которая занималась системами навигации больших судов. Ездовые коты, особенно нестарые - это такие создания, которые редко изучают документацию детально, а чаще бегло читают там про интерфейсы систем в проекте, malloc, new, системные аллокаторы и думают, что теперь-то точно понятно, как всё устроено. А потом приходит работа и такая: “Забудь всё, что ты знал. Ты не дочитал до страницы восемьсот что-то там РД, тут есть свой аллокатор - и он реально плохой”.
Примерно так началось мое погружение в мир ненормального распределения памяти. Это сейчас я знаю с десяток разных аллокаторов, и специфику их работы, специфика правда больше игровая, но думаю многим будет интересно - зачем нужны все эти "танцы с аллокаторами". В той статье все аллокаторы еще более менее нормальные, но есть еще ненормальные и они оказывается тоже нужны, и в определенных сферах разработки очень даже важны и применяются.
А вот почему нужны и важны ненормальные - объяснений почти нет, как и самих реализаций в открытом доступе. В этой статье я расскажу, какие повстречал ненормальные алгоритмы распределения памяти, чем они живут, кого едят, и почему иногда malloc делает вид, что он не при делах и таки да, malloc может возвращать null и ту проверку мы убрали зря.
Всем привет! Меня зовут Илья Кара́псин, я работаю над производительностью Яндекс Браузера. Задачи моей команды включают не только работу над самим браузером, но и прямое улучшение используемых в нём опенсорс‑решений, например Chromium и применяемых в нём проектов (Blink, V8, Catapult), в том числе и компиляторов (LLVM Clang). Другими словами, мы вносим вклад в сообщество. При этом поиск и создание улучшений для сторонних опенсорс‑проектов может стать прямой рабочей задачей даже в ходе стажировки.
К слову, моя работа в Браузере как раз с неё и началась. При отборе положительно сказалось наличие у меня pet‑проектов: отдельного внимания заслужил проект, использующий озвучку и SFX (сноска: сокращение от англ. sound effects — звуковые эффекты) из Heroes of Might and Magic V. Так удивительно совпало, что мой будущий руководитель ранее работал в Nival Interactive как раз над этой игрой.
А в этой статье я расскажу о том, как обычное сокращение полных файловых путей в логах до имени файла (например, path/to/filename → filename) может повлиять на размер исполняемых файлов и производительность Браузера, а также внести вклад в проект LLVM Clang.
Привет, Хабр!
Помню, как впервые запустил The Binding of Isaac: стартовая комната без подсказок, закрытые двери, на миникарте пусто. Пара забегов и у меня уже список технических вопросов по генерации этажей, приоритетам предметов, поведению врагов, рендеру и производительности. В тот момент я решил написать эту статью.
Сегодня я расскажу о разработке культовой инди-игры The Binding of Isaac и разберу технические нюансы: путь от Flash к C++, как собирается план этажа, как устроены большие комнаты и секретки, по каким правилам живут эффекты предметов и их синергии, как Lua-скрипты встраиваются в движок для модов, где в архитектуре сделаны осознанные компромиссы.
Когда речь заходит о корутинах (сопрограммах) на С++, большинство программистов вспоминает фреймворк coroutine_ts, появившийся в стандарте С++20. Многие даже не догадываются о том, что писать корутины можно было задолго до появления упомянутого стандарта. При этом можно было использовать не только С++, но и Си. Данной статьей я открываю серию, в которой хочу описать свой личный опыт изучения корутин и привести примеры их использования. Надеюсь мои статьи помогут начинающим разобраться в этой сложной и интересной теме.
Когда отлаживаешь программу, речь идет про использование отладчика в студии или другой IDE, то почти всегда имеешь дело с точками останова (breakpoint, бряками) — механизмом, когда выполнение программы приостанавливается, чтобы можно было заглянуть внутрь и понять, что происходит. Точек останова есть всего два основных типа, программные и аппаратные, а остальные все сделаны на их основе. Эти два базовых типа могут вести себя похоже, но устроены по-разному.
Программные точки останова — это то, с чем сталкивается каждый разработчик, когда вы ставите красную точку в среде разработки (в основном я использую большую студию) или используете команду bp под WinDbg. В этом случае отладчик просто подменяет один байт машинного кода в нужной инструкции на команду int 3. Это специальная инструкция для вызова прерывания отладки (Debug Interrupt), имеет машинный код 0xCC и говорит процессору: “Остановись, я хочу передать управление отладчику”, соответственно когда выполнение доходит до этой инструкции, срабатывает прерывание, и управление передаётся в отладчик. Отладчик "просыпается" и видит, что программа остановилась из-за исключения EXCEPTION_BREAKPOINT , возникшего по конкретному адресу, проверяет свой внутренний список точек останова и находит ту, которая была установлена по этому адресу.
Вычисление производных высших порядков полинома Ньютона
Интерполяция — задача восстановления функции по заданному дискретному набору её значений. При этом предполагается, что исходная функция является непрерывной на рассматриваемом отрезке. Одним из методов её решения является интерполяционный полином Ньютона.
Рассказ о самой полезной части Nix — управление пакетами из репозитория nixpkgs.
Я использовал и использую разные языки. В Rust есть прекрасный пакетный менеджер cargo и инсталлятор rustup, для JavaScript — npm. Мне также нравится conda в мире Python.
Мне всегда не хватало чего-то подобного для проектов на Си и C++. Пакетные менеджеры для этих языков часто оставляют желать лучшего. Даже если они работают, в их репозиториях может не быть нужных библиотек. Даже если вроде всё работает хорошо, может оказаться, что для работы бинарного кэширования нужно прилагать усилия, а когда это что-то вроде разных версий Qt — собирать всё на машине разработчика неприятно.
Я хотел, чтобы инструмент из коробки давал максимум без дополнительной настройки.
Поэтому я расскажу, как использовать Nix в качестве пакетного менеджера для Си и C++.
Сегодня Rust активно используется не только как язык для написания приложений, в том числе системных, но и как язык для написания библиотек, которые подключают к существующим проектам на C и C++. Это удобно: новую функциональность можно писать на Rust, но при этом не переписывать весь код на нём.
В этой статье мы рассмотрим процесс создания AppImage — универсального формата для распространения Linux-приложений. Ниже представлена ссылка на набор скриптов, который автоматизирует сборку AppImage, включая поиск зависимостей, копирование библиотек и упаковку приложения.
Зачем две темы в одной статье? Затем, что есть задачи, которые нуждаются в обоих механизмах, поэтому новичок, решивший освоить C++ для своих практических нужд, с помощью этой статьи может сразу приступить к реализации не слишком сложных проектов.
Для примера, вот список некоторых задач, которые решаются с помощью этих механизмов:
подмена/эмуляция нажатий клавиш, кнопок мыши;
автоматизация ввода, симуляция поведения пользователя в зависимости от содержимого на экране;
снимки с экрана (по нажатию клавиш или по таймингу);
замена статического содержимого с целью повышения комфорта работы (замена фона, повышение контраста шрифта, экранная лупа);
вывод компактных индикаторов/списков выбора в любой момент в любое место на экране;
превращение домашнего компьютера в медиацентр (беспроводная клавиатура + набор шаблонов для запуска фильмов, музыки, регулировки звука и частот + кресло/диван + большой монитор + печеньки :-) ).
Любопытно? Тогда прошу в статью!
Статья о реализации сервиса на C++ с применением TDD, DDD и событийно-ориентированной архитектуры. Проект переносит идеи из книги «Паттерны разработки на Python: TDD, DDD и событийно-ориентированная архитектура» на C++.
Всем привет! Сегодня хочу зажечь настоящий холивар — но с практическим уклоном. Речь пойдет о нашем большом рефакторинге, вернее, о почти полном переписывании ядра нашего API-гейтвея.
Немного контекста: У нас классический монолит на Java (Spring Boot), который неплохо служил нам лет 5. Но с ростом нагрузки до 100k+ RPS мы уперлись в лимиты:
Prometheus — система мониторинга самых различных устройств и приложений, самостоятельно сканирующая целевые объекты. В нашем случае, целевой объект — тестовый стенд с устройствами различных архитектур под управлением ОС «Нейтрино».
Так как Prometheus широко распространен, то для сбора и предоставления данных о метриках в нужном формате существует большое множество различных экспортёров, но все они либо заточены под работу на конкретных устройствах, либо избыточны, и содержат массу зависимостей.
Нам же требовался достаточно простой текстовый экспортёр, который бы стабильно работал в условиях использования встраиваемых систем с различными архитектурами процессора, и учитывал бы особенности и ограничения ОС.
Так и появился данный проект, доступный в нашем публичном репозитории, реализованный на С++11.
