C++ geek

При каких условиях ReadFile или WriteFile могут не передать все байты, и как это обнаружить? Один из клиентов хотел понять, в каких случаях функции ReadFile и WriteFile могут не передать все байты, и как определить, что это произошло. Очевидная причина, по которой ReadFile может не прочитать все байты, - это то, что просто нет такого количества данных для чтения. - Для файлов на диске это обычно происходит, если попытаться читать за концом файла. - То же может случиться и с другими типами дескрипторов: для pipe в неблокирующем режиме в пайпе может не оказаться достаточного количества данных. - Если это message pipe, сообщение может быть меньше, чем размер вашего буфера. - Или при обращении к устройству - оно может не иметь всех байтов в наличии. Аналогично, очевидная причина, по которой WriteFile может не записать все байты, — это нехватка места. - Для файлов на диске это может быть полный диск или достижение лимита квоты. - Для pipe в неблокирующем режиме запись может быть укорочена, если в буфере пайпа недостаточно места, чтобы принять все запрошенные данные. Во всех таких случаях укороченную запись можно обнаружить, проверив, меньше ли число реально записанных байт по сравнению с запрошенным. Если количество реально переданных байт больше нуля, то функции ReadFile и WriteFile вернут успех, но при этом передадут меньше байт, чем было запрошено. ➡️ @cpp_geek

🚀 Подборка полезных IT каналов в Max Системное администрирование, DevOps 📌 https://max.ru/i_odmin Все для системного администратора https://max.ru/bash_srv Bash Советы https://max.ru/sysadminof Книги для админов, полезные материалы https://max.ru/i_odmin_book Библиотека Системного Администратора https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др. 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С Программирование C++📌 https://max.ru/cpp_lib Библиотека C/C++ разработчика Программирование Python 📌 https://max.ru/python_of Python академия. https://max.ru/BookPython Библиотека Python разработчика Java разработка 📌 https://max.ru/bookjava Библиотека Java разработчика GitHub Сообщество 📌 https://max.ru/githublib Интересное из GitHub Базы данных (Data Base) 📌 https://max.ru/database_info Все про базы данных Фронтенд разработка 📌 https://max.ru/frontend_1 Подборки для frontend разработчиков Библиотеки 📌 https://max.ru/programmist_of Книги по программированию https://max.ru/proglb Библиотека программиста https://max.ru/bfbook Книги для программистов Программирование 📌 https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻 Шутки программистов 📌 https://max.ru/itumor Шутки программистов Защита, взлом, безопасность 📌 https://max.ru/thehaking Канал о кибербезопасности https://max.ru/xakkep_1 Хакер Free Книги, статьи для дизайнеров 📌 https://max.ru/odesigners Статьи, книги для дизайнеров Математика 📌 https://max.ru/Pomatematike Канал по математике https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике Вакансии 📌 https://max.ru/progjob Вакансии в IT Мир технологий 📌 https://max.ru/mir_teh Канал для любознательных Бонус 📌 https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга https://max.ru/mockva_life Свежие новости Москвы

🌉 Забудьте про передачу указателей и размеров! (std::span) Помните, мы обсуждали std::string_view - легковесное «окно» для строк? В C++20 у него появился старший брат для массивов и векторов - std::span. До C++20 у нас была классическая проблема. Допустим, вы пишете функцию, которая должна обработать список чисел. 🐢 Как мы писали раньше: Вариант 1: Принимать const std::vector<int>&. Минус: Функция теперь намертво привязана к std::vector. Если у вас данные лежат в std::array или обычном си-массиве int arr[10], придется копировать их в вектор. Аллокации, тормоза. Вариант 2: Си-стайл (Указатель + размер). Минус: Легко ошибиться с размером, потерять контекст, код выглядит грязно.

    
        
void ProcessOld(const int* data, size_t size) { /* ... */ }

{}
    

🚀 Как мы пишем теперь (C++20):

    
        
#include <span>

// Принимаем любой непрерывный кусок памяти!
void ProcessNew(std::span<const int> data) {
    for (int val : data) {
        std::cout << val << " ";
    }
}

{}
    

👀 Что такое std::span? Как и string_view, это просто указатель на начало данных и их длина (обычно 16 байт). Он не владеет памятью, он только на нее смотрит. Магия в том, что std::span умеет автоматически создаваться из чего угодно:

    
        
std::vector<int> vec = {1, 2, 3};
std::array<int, 3> arr = {4, 5, 6};
int raw[3] = {7, 8, 9};

// Одна функция работает со всеми типами контейнеров! Без копирования!
ProcessNew(vec); 
ProcessNew(arr);
ProcessNew(raw);

{}
    

✂️ Суперсила: Subspan (Подмассивы) Вам нужно передать в функцию только часть вектора, например, со 2-го по 5-й элемент? Никаких итераторов и копирования:

    
        
// Передаем кусок вектора за O(1)
ProcessNew( std::span{vec}.subspan(1, 4) ); 

{}
    

⚠️ Важный нюанс: std::span не умеет изменять размер данных (никаких push_back). Но он может изменять сами элементы, если вы передадите std::span<int> (без const). 💡 Итог: Если ваша функция принимает набор данных только для чтения или изменения элементов на месте, всегда используйте std::span. Это золотой стандарт современного C++. #cpp #cpp20 #stdspan #optimization #memory #coding #tips ➡️ @cpp_geek

🗺 std::map или std::unordered_map: Битва за кэш Когда нам нужно хранить пары «Ключ - Значение», рука сама тянется написать std::map. Это стандарт, это удобно, это сортировка из коробки. Но с точки зрения производительности std::map это часто худший выбор. Почему? 🌲 1. std::map - Это Дерево (Red-Black Tree) Каждый элемент в map - это отдельный узел (Node), выделенный в куче (new). Узлы разбросаны по памяти хаотично. • Чтобы найти элемент, процессор прыгает по указателям: Root -> Left -> Right -> ... • Каждый прыжок - это потенциальный Cache Miss (промах кэша). Процессор ждет сотни тактов, пока данные подтянутся из RAM. • Сложность поиска: O(log N). ⚡ 2. std::unordered_map - Это Хеш-таблица Здесь нет деревьев. Ключ превращается в число (хеш), и мы сразу прыгаем в нужную ячейку массива (Bucket). • Массивы любят кэш процессора (Cache Locality). • Сложность поиска: O(1) (в среднем). Это мгновенно. 🐢 Насколько велика разница? На маленьких объемах (до 100 элементов) разницы почти нет. Но на 1,000,000 элементов std::unordered_map может быть в 3-5 раз быстрее просто за счет отсутствия прыжков по памяти. 🤔 Когда использовать std::map? Только в одном случае: Вам жизненно важен порядок ключей. Например, если вы хотите вывести пользователей по алфавиту или найти диапазон дат (lower_bound / upper_bound). 🚀 Бонус: C++23 std::flat_map В новом стандарте завезли std::flat_map. Это гибрид: интерфейс как у map (сортированный), но внутри - сплошной вектор. Это самый быстрый вариант для поиска, но медленный для вставки. Если у вас C++23 - присмотритесь! 💡 Итог: если вам не нужна сортировка, всегда пишите std::unordered_map. Не заставляйте процессор бегать по дереву указателей без причины. #cpp #stl #optimization #performance #map #hashing #coding #tips ➡️ @cpp_geek

😱 std::vector<bool>: Великий обман C++ Вы думаете, что std::vector<bool> это просто вектор, который хранит булевы значения? Нет. Это совершенно уникальный монстр, который нарушает правила стандартной библиотеки. 📉 В чем подвох? Обычный bool занимает 1 байт (минимум адресуемой памяти). Но создатели C++ решили сэкономить память. std::vector<bool> - это специализация. Внутри него каждый bool занимает всего 1 бит. В одном байте хранится сразу 8 значений true/false. Экономия памяти в 8 раз! Круто? 🛑 Проблема: Вы не можете взять адрес элемента В C++ нельзя создать указатель или ссылку на отдельный бит. Память адресуется байтами.

    
        
std::vector<int> nums = {1, 2};
int* p = &nums[0]; // ✅ ОК. Указатель на первый int.

std::vector<bool> flags = {true, false};
bool* b = &flags[0]; // ❌ ОШИБКА КОМПИЛЯЦИИ!
// Мы не можем получить адрес бита.

{}
    

🤖 Проблема: Прокси-объекты Когда вы пишете flags[0], вектор возвращает не bool& (ссылку), а специальный временный объект - Proxy Class (std::vector<bool>::reference). Этот объект "притворяется" ссылкой. Когда вы присваиваете ему значение, он делает побитовые сдвиги и маски (&, |, <<), чтобы изменить нужный бит внутри байта. Это медленно. ⚠️ Ловушка с auto

    
        
std::vector<bool> vec = {true, false};

// Вы думаете, что val — это bool.
// На самом деле val — это 'std::vector<bool>::reference'.
auto val = vec[0]; 

vec.push_back(true); // Реаллокация памяти!

// 💥 Если val — это прокси, он может ссылаться на 
// старую, уже удаленную память вектора.
val = false; // Undefined Behavior / Crash

{}
    

💡 Что делать? 1. Если вам важна память: Используйте std::vector<bool> (или std::bitset для фиксированного размера). 2. Если вам важна скорость: Используйте std::vector<char> или std::vector<uint8_t>. Это займет в 8 раз больше памяти, но будет работать мгновенно, и вы получите нормальные ссылки. 3. Осторожно с auto: Всегда пишите тип явно: bool val = vec[0];, чтобы заставить прокси превратиться в значение. #cpp #stl #vector #gotchas #memory #coding #tips ➡️ @cpp_geek

🔒 const в C++: Скрытый смысл, о котором молчат Мы привыкли думать, что const после имени метода это просто защита от дурака: "Я обещаю не менять поля класса внутри этой функции". Но в современном C++ (и в стандартной библиотеке STL) const означает нечто большее. Это контракт потокобезопасности (Thread Safety Contract). 🧵 Золотое правило STL: 1. const методы можно вызывать из разных потоков одновременно без блокировок. (Safe for concurrent reads). 2. Не-const методы требуют внешней синхронизации, если их вызывают несколько потоков. 🚨 Где кроется ловушка? Ловушка в ключевом слове mutable. Оно позволяет менять поля даже внутри const метода. Обычно это используют для кэширования или ленивых вычислений. ❌ ОПАСНЫЙ КОД (Логический const, но физическая гонка):

    
        
class Widget {
    mutable int cachedValue_ = -1; // Можно менять в const методе

public:
    // Метод помечен const. Пользователь думает, что он безопасен 
    // для вызова из 10 потоков одновременно.
    int GetValue() const {
        if (cachedValue_ == -1) {
            // 💥 DATA RACE! 
            // Два потока могут одновременно зайти сюда и начать писать.
            cachedValue_ = HeavyCalculation(); 
        }
        return cachedValue_;
    }
};

{}
    

Если вы пишете библиотеку и помечаете метод как const, пользователи будут вызывать его параллельно, не используя мьютексы. Если внутри у вас есть несинхронизированный mutable - программа упадет. ✅ Правильный подход: Если вы используете mutable, вы обязаны защитить его мьютексом.

    
        
class Widget {
    mutable std::mutex mtx_; // Мьютекс тоже должен быть mutable!
    mutable int cachedValue_ = -1;

public:
    int GetValue() const {
        std::lock_guard<std::mutex> lock(mtx_); // Блокируем поток
        
        if (cachedValue_ == -1) {
            cachedValue_ = HeavyCalculation();
        }
        return cachedValue_;
    }
};

{}
    

💡 Итог: В C++ const - это не только "я не меняю данные". Это обещание: "Этот метод безопасен для одновременного вызова". Если вы нарушаете это обещание (используя mutable без защиты), вы создаете бомбу замедленного действия. #cpp #multithreading #const #safety #coding #tips ➡️ @cpp_geek

🏗 Тетрис в памяти: Почему порядок полей в классе важен? Вы создали простую структуру: bool, int и еще один bool. Математика проста: 1 байт + 4 байта + 1 байт = 6 байт. Вы проверяете через sizeof и видите... 12 байт. 🤯 Куда делись еще 6 байт? Вы только что потеряли 50% памяти на "воздух". Это называется Padding (Выравнивание). ⚙️ Как это работает? Процессор не любит читать данные по произвольным адресам. Ему удобно читать кусками по 4 или 8 байт (слова). Чтобы int (4 байта) не "разломился" посередине двух слов, компилятор вставляет пустые байты-заглушки. ❌ Плохой пример (Bad Layout):

    
        
struct Bad {
    bool a; // 1 байт
    // ... 3 байта PADDING (воздух) ...
    int b;  // 4 байта (должен начинаться с кратного 4 адреса)
    bool c; // 1 байт
    // ... 3 байта PADDING (чтобы выровнять общий размер) ...
};
// Итог: 12 байт

{}
    

✅ Хороший пример (Good Layout): Просто меняем порядок полей. Правило: "От больших к маленьким".

    
        
struct Good {
    int b;  // 4 байта
    bool a; // 1 байт
    bool c; // 1 байт
    // ... 2 байта PADDING (добиваем до кратности 4) ...
};
// Итог: 8 байт

{}
    

📉 Почему это важно? Кажется, что 4 байта ерунда. Но если у вас std::vector<Bad> на 1,000,000 элементов: ⚫️Bad: ~12 MB памяти. ⚫️Good: ~8 MB памяти. Вы экономите 4 мегабайта просто переставив строчки местами! Плюс, более плотные данные лучше ложатся в кэш процессора (CPU Cache), что ускоряет обработку. 💡 Совет: Объявляйте поля в порядке убывания их размера: 1. Указатели и double (8 байт) 2. int, float (4 байта) 3. short (2 байта) 4. bool, char (1 байт) #cpp #optimization #memory #alignment #coding #tips ➡️ @cpp_geek

🏗 Анатомия std::vector: Что происходит, когда место заканчивается? std::vector - самый популярный контейнер в C++. Мы просто пишем push_back, и магия работает. Но что происходит «под капотом», когда вы пытаетесь добавить элемент, а свободное место (capacity) закончилось? Происходит Реаллокация. И это гораздо дороже, чем просто добавление числа. ⚙️ Сценарий катастрофы (пошагово): Допустим, у вектора было место под 4 элемента, и оно занято. Вы добавляете 5-й. 1. Поиск новой земли: Вектор понимает, что текущий буфер полон. Он просит у операционной системы выделить новый блок памяти (обычно в 1.5 или 2 раза больше старого). 2. Великое переселение: Все элементы из старого блока копируются (или перемещаются) в новый. - Представьте: чтобы поставить на полку одну новую книгу, вам приходится переезжать в новую квартиру и перетаскивать туда всю библиотеку. 3. Зачистка: Старые объекты разрушаются (вызываются деструкторы), а старая память возвращается системе. 4. Вставка: И только теперь новый элемент добавляется в хвост. 🚨 Почему это проблема? 1. Удар по производительности Операция push_back обычно мгновенна (). Но при реаллокации она превращается в тяжелую операцию . Если вектор огромный, программа может «подвиснуть» в самый неподходящий момент. 2. Инвалидация ссылок (Источник багов №1) Это самое опасное. Как только произошла реаллокация, старая память удаляется. Все указатели, ссылки и итераторы, которые смотрели на элементы вектора, становятся невалидными.

    
        
std::vector<int> data = {1, 2, 3, 4};
int& ref = data[0]; // Ссылка на первый элемент

// Добавляем элемент -> места нет -> реаллокация!
data.push_back(5); 

// ☠️ ОШИБКА: ref ссылается на очищенную память.
// Получим мусор или краш программы.
std::cout << ref; 

{}
    

🛡 Как лечить? Если вы знаете (хотя бы примерно), сколько элементов будет в векторе - используйте reserve().

    
        
std::vector<int> data;
data.reserve(1000); // Сразу выделяем память

// Теперь реаллокации точно не будет, 
// пока мы не превысим 1000 элементов.

{}
    

💡 Итог: Помогайте вектору с помощью reserve(). Это спасает и от тормозов, и от сложнейших багов с памятью. #cpp #stdvector #memory #performance #coding #tips ➡️ @cpp_geek

🏗 Анатомия std::vector::push_back: Когда память заканчивается Мы все любим push_back. Это удобно: просто кидаешь данные в вектор, а он сам разбирается с памятью. Но что происходит, когда вы добавляете элемент, а место (capacity) закончилось? Происходит Реаллокация (Reallocation). И это дорогая операция. ⚙️ Что происходит «под капотом»? 1. Поиск новой земли: Вектор понимает, что текущий буфер полон. Он просит у операционной системы выделить новый блок памяти. Обычно он в 1.5 или 2 раза больше предыдущего (геометрический рост). 2. Великое переселение: Все элементы из старого блока копируются (или перемещаются, если есть noexcept move-конструктор) в новый блок. ⚫️Представьте, что вы перевозите 10,000 коробок в новый дом только ради того, чтобы поставить еще одну. 3. Зачистка: Для всех объектов в старом блоке вызываются деструкторы. 4. Снос: Старая память возвращается системе. 🚨 Почему это проблема? 1. Удар по производительности: Обычно push_back работает за амортизированное O(1) (мгновенно). Но в момент реаллокации сложность подскакивает до O(N). Это вызывает непредсказуемые лаги (latency spikes). 2. Инвалидация итераторов и ссылок (ОПАСНО): Это источник багов №1. После реаллокации старая память удалена. Все указатели, ссылки и итераторы, которые смотрели на элементы вектора, становятся недействительными.

    
        
std::vector<int> vec = {1, 2, 3};
int& ref = vec[0]; // Ссылка на первый элемент

// ... добавляем много элементов, вызывая реаллокацию ...
for(int i=0; i < 100; ++i) vec.push_back(i);

// 💥 Вектор переехал. Старая память удалена. 
// ref теперь указывает в мусор.
std::cout << ref; // Undefined Behavior (Crash или мусор)

{}
    

🛡 Как лечить? Если вы хотя бы примерно знаете, сколько элементов будет в векторе, всегда используйте reserve().

    
        
std::vector<User> users;
users.reserve(1000); // Сразу выделяем память под 1000 мест

// Теперь первые 1000 push_back будут дешевыми
// и гарантированно не вызовут реаллокации.

{}
    

💡 Итог: std::vector это мощный инструмент, но за его автоматическое расширение платит процессор. Помогайте ему через reserve(), чтобы код был быстрым и безопасным. #cpp #stdvector #performance #memory #coding #tips ➡️ @cpp_geek

📦 std::move vs std::forward: Когда и зачем? На собеседованиях часто спрашивают про rvalue-ссылки, но в реальном коде мы постоянно путаемся: когда делать move, а когда forward? Давайте разберем на жизненных примерах. 1. std::move - "Это мое, но забирай!" 🚚 std::move - это безусловное приведение к rvalue. Вы говорите компилятору: "Мне этот объект больше не нужен. Можешь выпотрошить его и забрать данные, не копируя их". Сценарий 1: Передача владения (unique_ptr) Это классика. std::unique_ptr нельзя скопировать, его можно только переместить.

    
        
auto ptr = std::make_unique<BigData>();

// process(ptr); // ❌ Ошибка компиляции! Копирование запрещено.
process(std::move(ptr)); // ✅ ОК. Владение передано, ptr теперь пуст.

{}
    

Сценарий 2: Оптимизация тяжелых объектов У вас есть локальный вектор, который вы хотите сохранить в поле класса. Зачем его копировать?

    
        
void SetData(std::vector<int> newData) {
    // Мы крадем буфер памяти у newData. 
    // Копирования элементов НЕ происходит.
    this->data_ = std::move(newData); 
}

{}
    

2. std::forward - "Я просто посредник" 📮 std::forward используется почти исключительно в шаблонах. Его цель - Perfect Forwarding (Идеальная передача). Представьте, что вы пишете функцию-обертку (wrapper). Она принимает аргумент и должна передать его дальше другой функции. ⚫️Если ей передали временный объект (rvalue) - она должна передать его как rvalue (чтобы сработал move). ⚫️Если передали обычную переменную (lvalue) - она должна передать как lvalue (копия). std::move здесь всё испортит (он всё превратит в rvalue). Тут нужен std::forward. Сценарий: Фабрики и Обертки

    
        
template <typename T>
void LogAndAdd(std::vector<T>& vec, T&& item) {
    std::cout << "Adding item...";
    
    // forward сохранит категорию значения item.
    // Если item был временным — сработает push_back(T&&) (перемещение).
    // Если item был переменной — сработает push_back(const T&) (копия).
    vec.push_back(std::forward<T>(item));
}

{}
    

⚡️ Шпаргалка 1. std::move используем, когда мы знаем, что объект нам больше не нужен, и мы хотим отдать его ресурсы (обычный код). 2. std::forward используем, когда мы пишем шаблон, который принимает "универсальную ссылку" (T&&), и нам нужно пробросить аргумент дальше "как есть" (библиотечный код). #cpp #cpp11 #movesemantics #coding #interview #tips ➡️ @cpp_geek