C++ *

Вы проводите код-ревью на текущем проекте или считаете что это просто пустая трата времени?

На собеседованиях я иногда спрашиваю, зачем проводят код-ревью. Вы можете удивиться, но один матерый senior, с 10+ лет в игрострое, и еще пятерку отмотавший в ембедед разработке за наглость получения красного диплома, ответил "потому что все так делают" - это конечно редкий запущенный случай, но было. Еще встречается такое - "потому что так сказал сенсей" (лид, бабушка, ажаль шеф - подставьте свое). Еще какой-то процент людей отвечали, "потому что так делают в гугле", и когда, заметьте не первый человек, на полном серьезе говорит это на собесах я начинаю сомневаться в способностях нашего tech-HR проводить первичное собеседование, а он, надо сказать, иногда еще пишет продуктовый код и эти самые ревью регулярно проходит наравне со всей командой разработки. Не сомневаться же людях, которые пришли?

Ни один процесс разработки программы не проходит без отладки. Современные IDE обеспечивают программиста встроенным отладчиком. Однако бывают ситуации, когда использование IDE для отладки избыточно или невозможно, и тогда на помощь приходят автономные отладчики, один из которых — x64dbg.

В C++ нет базового типа чисел с фиксированной точкой, в стандартной библиотеке также нет классов для них. В тоже время работа с числами с плавающей точкой (double, float) часто может быть неочевидна (например, ответьте на вопрос: ассоциативна ли операция сложения над ними?), вдобавок язык предоставляет (часто критикуемую) возможность перегрузки арифмитических операторов, подталкивая нас к созданию собственного типа данных.

Прежде чем писать код, давайте повторим мат. часть, а именно о представление чисел в типах uint8_t, int8_t и особенностях арифмитических операциях над ними. Итак, сложенение двух uint8_t происходит по модулю 256, то есть 1+2 = 3, но 1 + 255 = 0, для int8_t отрицательные значения можно ввести следущим образом: отрицательные числа соответсвуют тем безнаковым числам из uint8_t которые складываясь по модулю 256 дадут ноль, то есть -1 будем в памяти выглядить как 255 (FF). Границы типа int8_t -128...+127, для отрицательных чисел старший бит всегда равен 1. При умножении двух int8_t получаем результат типа int16_t, частное от деления int16_t на uint8_t будет иметь тип uint8_t. Все эти сведения носят аболютно тривиальный характер, но, они необходимы для дальнейшего понимания статьи.

Итак, перейдём к основной идее: что если мы мысленно возьмем значение типа int8_t и скажем, что теперь это не число единиц, а скажем, число 1/4 (проговорим словами: это число показывает сколько четвертых частей в исходном числе)? После чего инкапсулируем эту перменную в поле класса и перегрузим для него основные арифмитичекие операторы и напишем свой operator string() для правильного вывода таких чисел. Ниже, можно посмотреть, что получается из этой идеи.

Мы следим за жизнью всех ребят, которые приходят в ЦПМ и участвуют в наших проектах. Каждый раз, когда мы узнаем об их достижениях, нам очень трепетно и радостно! Сегодня мы хотим поделиться историей Артёма Мазура, который прошел на стажировку, внимание, в VK!

Знаете ли вы куда попадает ваша программа после того, как вы нажали кнопку RUN или DEBUG в IDE? Если да, то как изменить этот адрес или даже выйти за пределы постоянной памяти и прожигаться сразу в оперативную память? Небольшая статья, которую я сам в свое время не нашел и потратил много часов и нервов на сбор этой не хитрой информации.

Друзья-разработчики, приглашаем вас продолжить захватывающее путешествие по дебрям кода Intel OpenVINO! Вооружившись статическим анализатором аки детективы, мы разоблачим наиболее коварные, интересные ошибки и опечатки, а также их скрытые тайны, оставшиеся за рамками первой части статьи.

Если вы посмотрите на общую раздутость современного софта, загружаемые 100 гигабайтные игры, ежегодную Nvidia X090 дающую +20% год от года, и 20-ядерные процессоры, то со стороны может показаться, что оптимизация производительности неважно чего, будь то игры или другой софт, казалось бы, утратила свою актуальность. В эпоху безнаказанной производительности аппаратной части можно расплескивать хоть половину этой мощи, и пользователь этого даже не заметит. Это все может и верно, если вы не делаете игру. Почему же тогда на этих двадцати ядрах, фризит и тормозит (хорошо что не вылетает часто) игра выпущенная два года назад?

Почему тормозит я вам не скажу: возможно разработчики, которые делали её (на не самом новом движке, надо сказать) просто делали игру и не задумывались о рядовых игроках, которые сидят на пятилетнем железе, хотя даже пятилетнее железо уделывает приставки текущего поколения. Возможно это другая причина - когда твоя рабочая машина с 64 гибайтами оперативки и 4080 на борту тянет редактор, то беспокоиться об игроках можно начинать после патча первого дня.

При том, что все эти 30 — 60 — 120 — 200 фпс в играх, это чисто маркетинговый показатель, это время с которой движок может создавать фреймы для видеокарты, но движок это не только картинка, есть физика — а она как работала на 30 фпсах 10 лет назад, так и работает. Или звуковая подсистема, так она вообще своей отдельной жизнью живет в своих приоритетных тредах, мы просто кидаем туда меседжи с настройками и номером фрейма, чтобы засинхронизировать это с картинкой. Это сложно, но решаемо, но звук не привязан к картинке.

Лучший способ научиться чему‑то — научить других. Второй лучший способ научиться чему‑то — сделать это самому. Я решил объединить эти два способа и научить себя и вас программировать DeFi сервисы на Ethereum (и любых других блокчейнах, основанных на EVM — Ethereum Virtual Machine).

Мы сосредоточимся на том, как работают эти сервисы, попытаемся понять экономическую механику, которая делает их такими, какие они есть (а все DeFi основаны на экономической механике). Мы будем выяснять, разбирать, изучать и создавать основные механизмы DeFi.

Привет, Хабр! Меня зовут Николай, я разработчик С++ в SimbirSoft. В предыдущей статье мы с вами рассмотрели применение стандартных алгоритмов в повседневном коде и их преимущества над обычными циклами. В продолжение этой темы мне хотелось бы рассказать о недостатках стандартных алгоритмов и способах их решения с помощью библиотеки Ranges. Практические примеры я разбил на три части: в первой показаны обычные циклы, во второй — вариант написания с помощью алгоритмов (но не всегда можно это сделать), в третьей – с использованием Ranges. Этот материал будет полезен тем разработчикам, которые хотят применять новые стандарты и подходы у себя на проектах.

Так прошло три дня. В комнате темно и холодно, но мониторы слепят. Ты дезориентирован настолько, как будто тебя кидает из одного диссоциативного эпизода в другой. Тебя то и дело пробивает нервный смех, хотя смеяться нечему. Как я здесь оказался? В чём моя вина?  

Главная ошибка была в том, что ты в это вообще ввязался — в этом никаких сомнений.

Ещё когда я впервые взялся проходить курс по C++ несколько лет назад, меня учили, что, если я не предоставлю собственного конструктора, то компилятор сам подберёт ему замену — своего рода конструкторы, действующие по умолчанию. Я решил подробнее в этом разобраться, особенно меня волновали случаи, которые выглядят примерно так:

-   const Color color { (u8)block.y[pixel_index], (u8)block.cb[pixel_index], (u8)block.cr[pixel_index] };
+   const Color color { (u8)block.cr[pixel_index], (u8)block.cb[pixel_index], (u8)block.y[pixel_index] };
    context.bitmap->set_pixel(x, y, color);

Предыдущая статья натолкнула меня на мысль написать ещё одну программу, генерирующую последовательности изображений с другим типом фракталов. В ней пришлось применить более сложную анимацию коэффициентов.

Всем привет. На Хабре есть довольно большое количество примеров реализации gRPC‑серверов на GO, чуть в меньшей степени на python, еще меньше — на других языках. Поиск примеров данного проекта для C++ дал мне не так много информации, как хотелось бы. К счастью, очень крутое решение-экземпляр есть на официальном сайте (ссылка). Если вам не хочется читать код и комментарии на английском языке, добро пожаловать под кат.

Недавно у нас в команде зашла дискуссия о неопределённом поведении (UB) в C. Напомню для тех, кто не знает: если мы пишем такой код, эффект от выполнения которого (и события в процессе его выполнения) строго не определён в спецификации языка, то возникает неопределённое поведение. Таким образом, встретив такой код, компилятор может действовать по собственному усмотрению, и нет никаких гарантий, что выполнение этого кода пойдёт по предсказуемому пути. Следовательно, нужно избегать неопределённого поведения любой ценой, поскольку мало того, что оно может приводить к глюкам программы, но и часто становится источником уязвимостей и угрозой безопасности. Примеры кода, в котором проявляется неопределённое поведение: выход за границы массива при его индексировании, целочисленное переполнение, деление на ноль, разыменование указателя на null [1].

Компиляторы нередко пользуются неопределённой семантикой языка, чтобы делать те или иные допущения о программе. Например, если написать что-то вроде int x = y/z, компилятор может предположить, что z не может быть равно нулю, так как деление на ноль приводит к неопределённому поведению, а программист явно не собирался писать такой код. На основе этой информации он может попытаться далее оптимизировать программу так:

Приветствую всех!

Сегодня я вам представлю свои наработки по способу инжекта 64-битных DLL библиотек в процессы WOW64, сам который считал невозможным. Любителей потрогать внутренности Windows приглашаю под кат.

Представим, что у вас идеальный проект. Таски пилятся, компилятор компилирует, статические анализаторы анализируют, релизы релизятся. В какой‑то момент вы принимаете волевое решение открыть древний файл, в который никто не залезал уже много лет, и видите, что он в кодировке Windows-1251. При том, что весь проект уже давно перешёл на UTF-8. «Непорядок!» — думаете вы, и лёгким движением руки меняете кодировку. На следующий день на вашем тестовом сервере случается локальный апокалипсис. Думаете, такого не может быть? Тогда предлагаю это обсудить.

Реализации объектно-ориентированного программирования в разных Си-подобных языках, конечно, похожи, и все такие языки, созданные после C++, пытаются сделать ООП более удобно используемым. Сравним в этой статье ООП в D и С++.

Никогда особо не стремился в большие компании, по душе всегда были небольшие уютные игровые студии, где и "отеческий" нагоняй от лида получить легко, да и самому "парой ласковых" объяснить коллегам где они были не правы можно. Но конечно шальные мысли, а вот если бы в Я..., да какой-нибудь еще фейсгугл попробоваться. Жаль только они не делают игры, но мысль эта таилась на закорках подсознания, периодически напоминая о себе в моменты просмотра объявлений, да после писем рекрутеров на linkedin. Около года назад два моих знакомых, которые давно уже живут на другом континенте, но с кем застали еще распад питерского EA, вдруг объявились на страничке в linkedin, оставили отзывы да отсыпали скилов. Сначала я не придал этому особого значения, мало ли чего там себе люди думают, может просто сеть знакомых обновляют, есть у них там за океаном такая забава. И так получилось, что на эти отзывы сагрились hr-боты большого G..., что и привело в дальнейшем к очень интересному опыту взаимодействия с людьми, знакомством с кухней отбора, этапами собеседования и воронкой "смерти" входа. Осторожнее надо быть со своими желаниями.

Где-то уже на хабре были статьи и про G... и про Я..., такие, что читая описания задачек на собесах, волевым решением на следующее утро начинал решать leetcode. Воли обычно хватало где-то на неделю, а потом рутина боевых задач и митинги затаскивали обратно в уютную берлогу не очень большого игростроя. Почему я решил написать об этом только через год после всех событий? Да банально подмахнул на третьем собеседовании NDA о методах проведения интервью, а когда понял ЧТО подписал - уже было поздно.

Как именно вы спроектировали бы оптимизирующий компилятор? Точнее, как именно вы спроектировали и реализовали бы конкретные оптимизации? Попытка решить эту задачу за один присест — дело ошеломительно сложное и, пожалуй, даже невозможное, так как оптимизации компилятора во многом заключаются в следующем...