🖥 Gooey — нативный кроссплатформенный GUI-фреймворк на C

Если ты разрабатываешь под Windows или Linux и хочешь лёгкий и настраиваемый UI, присмотрись к Gooey — фреймворку с нативной производительностью и открытым кодом.

✍ Почему стоит:
• 🔥 На C, без библиотек-монстров
• 🔴 Работает везде
• 🧩 Кастомный UI
• 💥 Лёгкий и быстрый
• 🧪 С GPL v2 и сообществом

🚀 GitHub

@cpluspluc

✔️ ЗАДАЧА: Что выведет код?

#include <iostream>
#include <vector>

struct Tracer {
  Tracer(const char* name) : name(name) {
    std::cout << "Constructing " << name << "\n";
  }
  ~Tracer() {
    std::cout << "Destructing " << name << "\n";
  }
  const char* name;
};

struct Example {
  Tracer t1{"t1"};
  std::vector<Tracer> list;
  Tracer t2{"t2"};

  Example() : list{Tracer("temp1"), Tracer("temp2")} {
    std::cout << "Inside constructor\n";
  }
};

int main() {
  Example e;
  std::cout << "End of main\n";
  return 0;
}

---

ОТВЕТ:

Constructing t1
Constructing temp1
Constructing temp2
Inside constructor
Constructing t2
End of main
Destructing t2
Destructing temp2
Destructing temp1
Destructing t1

---

Почему так:

• Поля инициализируются в порядке объявления в структуре, а не в списке инициализации
• std::initializer_list создаёт временные объекты, которые копируются в вектор
• t2 создаётся после строки Inside constructor
• Деструкторы вызываются в обратном порядке: t2 → temp2 → temp1 → t1

Хитрость — в порядке инициализации, временных объектах и destructuring-порядке!

@cpluspluc

🖥 less_slow.cpp — это образовательный репозиторий, который демонстрирует практики написания высокоэффективного кода на C++, C, CUDA, PTX и ассемблере.

Цель проекта — помочь разработчикам развить интуицию и мышление, ориентированные на производительность.​

🔍 Основные темы проекта:
- Микробенчмарки: Измерение производительности базовых операций, таких как сложение целых чисел, с использованием различных подходов, включая inline-ассемблер.

- Параллелизм и сложность вычислений: Анализ производительности стандартных алгоритмов сортировки и их оптимизация с использованием различных техник.

- Рекурсия: Сравнение рекурсивных и итеративных реализаций алгоритмов, таких как QuickSort, с акцентом на производительность и использование стека.

- Оптимизация стандартных функций: Примеры ускорения стандартных функций, таких как std::sin, с использованием приближений и SIMD-инструкций.

- Работа с JSON: Эффективный парсинг JSON без лишних аллокаций памяти, использование альтернатив стандартным библиотекам.​
GitHub
Hacker News

🛠️ Инструменты и технологии:
- Использование C++20 и современных компиляторов (GCC, Clang) для демонстрации новых возможностей языка.

- Интеграция с Google Benchmark для проведения точных измерений производительности.

- Примеры кода на CUDA, PTX и ассемблере для демонстрации низкоуровневой оптимизации.

- Использование сторонних библиотек, таких как fmt, range-v3, libunifex, cppcoro, liburing, oneTBB, ASIO, CUTLASS, CTRE, yyjson, Abseil, StringZilla и другие, для расширения функциональности и повышения производительности.​

📚 Дополнительные ресурсы:
Проект является частью серии "Less Slow", которая также включает реализации на Rust и Python.

Блог автора содержит подробные статьи по темам, затронутым в проекте: ashvardanian.com/tags/less-slow.​

Если вы хотите глубже понять, как писать эффективный код и избегать распространённых ошибок, less_slow.cpp станет отличным практическим пособием.

▪Github
▪Rust
▪Python.


@cpluspluc

🖥 Dear ImGui — библиотека GUI на C++ для быстрого создания интерфейсов без внешних зависимостей.

Оптимизирована для экономии памяти и легкой интеграции в проекты.

Позволяет быстро настраивать UI, избегая проблем с синхронизацией, и поддерживает разные графические API и платформы.

🔗 https://github.com/ocornut/imgui

@cpluspluc

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

💡 Автор объясняет, что компиляторы, следуя правилу "as-if" (как если бы), могут применять любые преобразования кода, при условии, что они не изменяют его наблюдаемое поведение. Однако, если в программе присутствует неопределенное поведение, компилятор может производить оптимизации, которые изменяют поведение программы, поскольку исходное поведение не было строго определено

🔗 Ссылка: *клик*

@cpluspluc

🖥 Задача для собеседования: "Быстрая очередь с удалением элемента за O(1)"

🔖 Условие:

Реализуйте структуру данных — очередь (`queue`), поддерживающую три операции:

- enqueue(x) — добавить элемент в конец очереди (должно работать за O(1));
- dequeue() — удалить элемент из начала очереди и вернуть его (должно работать за O(1));
- remove(x) — удалить первое вхождение элемента x из очереди за O(1).

Ограничения:
- Элементы могут повторяться.
- Если элемент отсутствует, remove(x) не делает ничего.
- Операции должны оставаться эффективными на больших объемах данных (миллионы элементов).
- Можно использовать стандартные структуры данных STL (`list`, unordered_map, unordered_set и т.д.).

▪️ Дополнительные вопросы к кандидату:

- Как обеспечить O(1) удаление произвольного элемента из очереди?
- Как избежать утечек памяти или "битых" итераторов после удаления элементов?
- Что будет, если очередь будет содержать множество одинаковых элементов?
- Как бы вы изменили решение, если бы нужно было удалять все вхождения элемента, а не только первое?

---

▪️ Разбор возможного решения:

Основная архитектура:

- Используем std::list<int> data для хранения реальной очереди.
- Почему list? Потому что позволяет за O(1) удалять элементы по итератору.
- Используем std::unordered_map<int, std::list<std::list<int>::iterator>> index.
- Для каждого значения храним список итераторов на его вхождения в data.

Операции:

- enqueue(x):
- Добавляем x в конец data.
- Сохраняем итератор на него в index[x].
- Все действия — за O(1).

- dequeue():
- Удаляем элемент из начала data.
- Находим соответствующий итератор в index, удаляем его.
- Если в списке итераторов для этого значения больше нет элементов, удаляем ключ из index.

- remove(x):
- Если в index[x] есть итераторы:
- Берем первый итератор.
- Удаляем его из data и из списка итераторов.
- Если список стал пустым — удаляем запись x из index.
- Все действия — за O(1).

---

▪️ Возможные подводные камни:

- ❗ Не проверять, пустой ли index[x], перед удалением итератора.
- ❗ Не удалять ключи из unordered_map, что приводит к накоплению "пустых" списков в памяти.
- ❗ Использовать vector вместо list — тогда удаление из середины будет занимать O(n).

---

▪️ Мини-пример интерфейса класса:

#include <list>
#include <unordered_map>

class FastQueue {
private:
    std::list<int> data;
    std::unordered_map<int, std::list<std::list<int>::iterator>> index;

public:
    void enqueue(int x) {
        auto it = data.insert(data.end(), x);
        index[x].push_back(it);
    }

    int dequeue() {
        if (data.empty()) throw std::out_of_range("Queue is empty");
        int val = data.front();
        auto it = index[val].front();
        index[val].pop_front();
        if (index[val].empty()) {
            index.erase(val);
        }
        data.pop_front();
        return val;
    }

    void remove(int x) {
        if (index.count(x) == 0) return;
        auto it = index[x].front();
        data.erase(it);
        index[x].pop_front();
        if (index[x].empty()) {
            index.erase(x);
        }
    }
};

▪️ Дополнительные вопросы на усложнение:

- Что если нужно сделать removeAll(x) — удаление всех вхождений элемента?
- Как изменится решение, если в очереди будут сложные объекты вместо int?
- Как минимизировать использование памяти, если очередь очень большая?
- Как обеспечить безопасность потоков (thread-safety) для многопоточного варианта очереди?

@cpluspluc