C++ *

На дворе 2021 год, я занимаюсь ремонтом электроники уже на протяжении десяти лет. Свободное от работы время посвящаю изучению 3D-моделирования и печати. Для этих целей в 2018 году были куплены два самодельных FDM-принтера.

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

Уже вечером этого дня я изучаю плату и узнаю такие слова, как "Asic", майнер, майнинг. Понимаю, что имею на руках плату одного такого устройства, а в данном случае — AntMiner S9.

Введение

#include <math.h>
float CalcCircumference1(float d)
{
    return d * M_PI;
}

Всем привет! Думаю, у многих сразу возник другой вопрос — а зачем вообще нужна ещё одна статья про LLVM, ведь на хабре их и так больше сотни? Моей задачей было написать "введение в тему" for the rest of us — профессиональных разработчиков, не планирующих создавать компиляторы и совершенно не интересующихся особенностями устройства LLVM IR. Насколько я знаю, подобного ещё не было.

Главное, что интересует практически всех — и о чём я планирую рассказать — вынесено в заголовок статьи. Зачем нужен LLVM, когда есть GCC и Visual C++? А если вы не программируете на C++, вам стоит беспокоиться? И вообще, LLVM это Clang? Или нет? И что эти четыре буквы на самом деле означают?

В std::move никто никуда не двигается

В undefined behavior поведение вполне себе определено, просто крашит игру

В GameObject нет ни игры ни объекта, а только баги и куча антипаттернов

Memory leak detector сам протекает

В PhysicsEngine физики столько же, сколько в сказке про Колобка

Из 8 часов работы 6 уходят на попытку собрать билд после мержа со стейблом.

В ProfileMode тормозит всё кроме профайлера

В retrospective meeting обсуждают, почему всё плохо, но оставляют как есть.

В debug билде багов меньше чем в релизном и выше фпс

• auto
• nullptr
• range-based циклы
• override и final
• строго-типизированный enum
• интеллектуальные указатели
• лямбды
• non-member begin() и end()
• static_assert и классы свойств
• семантика перемещения

16 декабря сего года, команда разработчиков ReactOS, спустя долгое время после последнего релиза (с последнего прошло почти полтора года) выпустила новую версию под номером 0.4.14. Это все еще альфа-версия.

В данной статье мы рассмотрим основные новшества как со стороны разработчиков, так и со стороны сообщества.

Масштаб

• Разработка программного обеспечения для государственного агентства.
• Сложность низкая, с несколькими вывертами.

В конце концов я должен был к этому прийти. Когда-то я опубликовал статью «Я написал быструю хеш-таблицу», а потом ещё одну — «Я написал ещё более быструю хеш-таблицу». Теперь я завершил работу над самой быстрой хеш-таблицей. И под этим я подразумеваю, что реализовал самый быстрый поиск по сравнению со всеми хеш-таблицами, какие мне только удалось найти. При этом операции вставки и удаления также работают очень быстро (хотя и не быстрее конкурентов).

Я использовал хеширование по алгоритму Robin Hood с ограничением максимального количества наборов. Если элемент должен быть на расстоянии больше Х позиций от своей идеальной позиции, то увеличиваем таблицу и надеемся, что в этом случае каждый элемент сможет быть ближе к своей желаемой позиции. Похоже, такой подход действительно хорошо работает. Величина Х может быть относительно невелика, что позволяет реализовать некоторые оптимизации внутреннего цикла поиска по хеш-таблице.

Если вы хотите только попробовать её в работе, то можете скачать отсюда. Либо пролистайте вниз до раздела «Исходный код и использование». Хотите подробностей — читайте дальше.