Работа с void* в стиле C++

Передача указателя на набор полей примитивных типов, расположенных в определённом порядке, - широко используемый паттерн. Так передаются указатели на структуры и объекты, массивы, файловые и сетевые буферы, данные в общей памяти и специальные типы (к примеру, массивы виртуальных функций), а отладчик, получив указатель на стек, может просматривать значения содержащихся в нём переменных.

Если набор полей, доступный по указателю, содержит данные различных типов, обычной практикой является определение типов структур, описывающих расположение полей в наборе. Так, заголовочные файлы Windows содержат сотни подобных типов. Для C/C++, допускающих прямые арифметические операции над указателями, данная возможность является, скорее, синтаксическим сахаром, существенно упрощающим доступ к таким полям, тогда как для языков, строже следящих за типобезопасностью, она может быть единственной.

Тем не менее, подход с определением структур имеет свои недостатки. Во-первых, количество типов имеет тенденцию быстро расти с усложнением API. Во-вторых, код работы с каждым типом структуры нужно писать (или генерировать) отдельно - или же делать типы шаблонными, теряя возможность дать каждому полю осмысленное имя. В-третьих, в ситуациях, когда порядок и типы полей не известны во время компиляции, написать соответствующий тип структуры попросту невозможно.

В данной статье я хочу показать принятую в нашем проекте организацию работы с подобными наборами полей в стиле C++ - через соответствующие типы итераторов.

Постановка задачи

Имеется указатель на последовательность двоичных полей примитивных типов, организованных в записи. Требуется определить итераторы, которые могут использоваться для перемещения по данной последовательности, чтения и записи отдельных полей. При этом:

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

2. Размер, по которому выравниваются поля, в одних случаях известен во время компиляции, в других (например, при возврате итератора из виртуальной функции, принимающей размер поля как аргумент) - во время выполнения.

3. Поля последовательности могут быть одного типа или разных типов. В первом случае итератор работает как обычный итератор C++, во втором - допускает чтение и запись любых примитивных типов, размер которых не превышает текущий размер выравнивания полей.

4. Порядок байтов в полях может совпадать с естественным порядком байтов данной платформы (big или little endian) или с сетевым порядком байтов (всегда big endian).

5. В одних случаях порядок байтов известен во время компиляции, в других (например, при возврате итератора виртуальной функцией, осуществляющей доступ к локальным или доступным по сети данным) - только во время выполнения. Хранить и проверять состояние нужно во втором случае, но не в первом (оптимизация). На платформе, где сетевой порядок байтов совпадает с естественным, хранить и проверять состояние не нужно никогда.

6. Поля, к которым осуществляется доступ, могут иметь гарантию правильного выравнивания или не иметь такой гарантии. В первом случае доступ к ним нужно проводить в конечных типах (соответствующие команды копирования многобайтных слов будут корректно работать на всех платформах), тогда как во втором случае требуется побайтовое копирование.

7. Операции чтения и записи, перемещения по последовательности и произвольного доступа к её элементам должны осуществляться в обычной для итераторов C++ форме.

8. Итератор может допускать доступ для чтения и записи или только для чтения (const-итератор).

В качестве стандарта реализации был выбран C++20.

Архитектура

В первой версии описываемого кода типов итератора было 4: binary_record_iterator, binary_record_const_iterator, specialized_binary_record_iterator и specialized_binary_record_const_iterator. Типы без суффикса const позволяли модифицировать последовательность, типы с таким суффиксом - не позволяли. Типы с префиксом specialized работали с последовательностями полей одного и того же типа, а типы без этого префикса - с последовательностями полей разных типов.

Практика показала, что 90% кода этих типов совпадает или отличается незначительно, посему в конечном счёте четыре класса слились в один. Сам класс получился шаблонным, с четырьмя аргументами:

1. Тип поля последовательности: void позволяет работать с любым типом, любой другой тип - только со значениями данного типа.

2. Стратегия копирования содержимого полей.

3. Стратегия определения размера поля.

4. Булев флаг - признак константности последовательности, по которой осуществляется итерация.

Стратегия копирования содержимого полей осуществляет непосредственно чтение и запись полей, доступных по указателю. Доступны несколько типов стратегий:

Необходимость побайтового копирования полей в ряде случаев может быть неочевидна. Тем не менее, существуют ситуации, когда просто так привести указатель к типу значения, разыменовать и выполнить присваивание нельзя - например, если данные прочитаны из файла или приняты по сети и находятся в буфере с неверным выравниванием. В зависимости от компилятора и процессора операция прямого присваивания таких значений может дать неверный результат, поскольку определённые команды копирования многобайтовых слов предполагают, что данные размещены в памяти с корректным выравниванием.

В своё время ваш покорный слуга наступил на эти грабли при разработке SCADA-системы на базе ARM-компьютера Moxa UC-7110. При чтении значения с плавающей точкой, доступного по указателю, оно отличалось от ожидаемого, хотя побайтовое сравнение показывало идентичность эталону. Использование функции memcpy() вместо простого разыменования с присваиванием позволило решить проблему.

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

Таким образом, при чтении значений, гарантированно имеющих естественный порядок байтов, используются native_field_copier или endianness_keeper, в зависимости от наличия гарантий на выравнивание полей. В случаях, когда порядок полей нужно всегда менять на противоположный, используется endianness_reverser. Наконец, если алгоритм должен работать как с прямым, так и с обратным порядком байтов, используется стратегия endianness_converter - самая тяжёлая за счёт хранения и проверки флага состояния.

Для проверки того, какое выравнивание является естественным для данной платформы, используется заголовочник <bit>, который как раз подвезли в C++20. Фактически используемые типы стратегий копирования значений определены следующим образом:

static constexpr std::endian network_byte_order = std::endian::big;
using local_or_network_field_copier =
    std::conditional_t<std::endian::native == network_byte_order,
                       endianness_keeper, endianness_converter>;
using network_field_copier =
    std::conditional_t<std::endian::native == network_byte_order,
                       endianness_keeper, endianness_reverser>;

local_or_network_field_copier используется там, где требуется доступ к данным, полученным локально или по сети, а network_field_copier - там, где ведётся работа исключительно с сетевыми данными. Такое определение переводит максимальное количество проверок на этап компиляции. Там, где данные заведомо имеют корректное выравнивание, используется native_field_copier.

Стратегий определения размера поля всего две, и они гораздо проще:

Итераторы предоставляют стандартные операции: пре- и пост-инкремент и декремент, а также операторы +, -, += и -= с аргументами типа size_t и ptrdiff_t. Единицей перемещения является поле, размер которого определяется текущей стратегией ширины поля. Для определения взаимного расположения двух итераторов доступен полный комплект операторов сравнения, а также оператор -. Присутствует также синтаксический сахар: операторы проверки на (не)равенство nullptr и дублирующие их операторы ! и приведения к bool.

Для доступа к данным используются операторы разыменования и доступа по индексу. Кроме того, доступны методы для чтения (у любых итераторов) и записи (у неконстантных) полей с автоматическим перемещением к следующему полю, а также для получения текущих размера поля и указателя на данные. Также есть специальный метод для чтения 64-битной записи в тип size_t с контролем переполнения для 32- и менее битных платформ.

Метод specialize() используется для перехода от нетипизированных итераторов к типизированным. Метод with_record_size фиксирует размер поля, заменяя текущую стратегию стратегией fixed_record_size с переданным аргументом шаблона.

Реализация

Экземпляры стратегий копирования байтов и определения размера поля включены в экземпляр итератора - закрытым наследованием, чтобы сэкономить место при отсутствии состояния у стратегии.

Итератор, сконструированный конструктором по умолчанию или с единственным nullptr-аргументом, не указывает на какие-либо данные. Также доступны конструкторы копирования и перемещения и соответствующие операторы присваивания. Основные же конструкторы принимают обязательный указатель на данные (const void* для константного итератора, void* для обычного) и аргументы стратегий.

В качестве аргументов стратегий могут быть переданы экземпляры самих стратегий. Альтернативно, для стратегии копирования данных можно передать порядок байт (std::endian) или признак его инверсии, а для стратегии определения размера поля - значение этого самого размера в байтах. Стратегии, допускающие изменение параметра в рантайме, сохраняют переданное значение, а не имеющие состояния - проверяют (через assert), что переданное значение соответствует их поведению. Аргументы для стратегий, имеющих состояние, обязательны, для не имеющих состояния - опциональны.

Указатель на данные всегда хранится как char* или const char* для удобства навигации по полям. Операции перемещения по данным выглядят тривиально:

template <typename element_type, typename field_copier, typename record_size_policy,
          bool is_const>
class binary_record_iterator : private field_copier, private record_size_policy
{
public:
    binary_record_iterator& operator+=(std::ptrdiff_t offset)
    {
        assert(is_forward_offset_valid(offset));
        m_data += offset *
                  static_cast<ptrdiff_t>(record_size_policy::get_record_size());
        return *this;
    }
};

Здесь is_forward_offset_valid() - простейшая проверка переполнения при выполнении арифметических операций с указателями. Поскольку данных о доступном диапазоне данных у итератора нет, выход за его границы не контролируется.

template <typename element_type, typename field_copier, typename record_size_policy,
          bool is_const>
class binary_record_iterator : private field_copier, private record_size_policy
{
private:
    bool is_forward_offset_valid(std::ptrdiff_t offset) const
    {
        if (offset >= 0)
            return std::numeric_limits<std::ptrdiff_t>::max() /
                   static_cast<std::ptrdiff_t>(record_size_policy::get_record_size())
                   >= offset
                &&
                   m_data + offset *
                   static_cast<ptrdiff_t>(record_size_policy::get_record_size())
                   >= m_data;
        else
            return std::numeric_limits<std::ptrdiff_t>::min() /
                   static_cast<std::ptrdiff_t>(record_size_policy::get_record_size())
                   <= offset
                &&
                   m_data + offset *
                   static_cast<ptrdiff_t>(record_size_policy::get_record_size())
                   < m_data;
    }
};

Для совместимости со стандартными алгоритмами определены типы-члены iterator_category, value_type, difference_type, reference и pointer.

Доступ к значению при разыменовании итератора осуществляется при помощи вспомогательного класса binary_record_reference, имеющего те же аргументы шаблона, что и класс итератора. Как и итератор, binary_record_reference содержит указатель на данные типа char* или const char*, а также наследует стратегии копирования данных и определения размера поля в закрытом режиме. Первая стратегия используется по прямому назначению, вторая - для проверки того, что размер копируемого значения не превышает размера поля.

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

Чтение и запись поля фиксированного типа выглядят тривиально:

template <typename element_type, typename field_copier, typename record_size_policy,
          bool is_const>
class binary_record_reference : private field_copier, private record_size_policy
{
public:
    operator element_type() const
    {
        assert(sizeof(element_type) <= record_size_policy::get_record_size());
    
        element_type value;
        field_copier::read(m_data, &value);
        return value;
    }
    template <bool is_const2 = is_const, typename = std::enable_if_t<!is_const2>>
    binary_record_reference& operator=(element_type value)
    {
        assert(sizeof(element_type) <= record_size_policy::get_record_size());

        // Если обмануть компилятор, передав явный аргумент is_const2 = false при
        // is_const = true, следующая строка всё равно не скомпилируется
        field_copier::write(value, m_data);
        return *this;
    }
};

Чтение и запись полей произвольных типов реализованы аналогично:

template <typename field_copier, typename record_size_policy, bool is_const>
class binary_record_reference<void, field_copier, record_size_policy, is_const> :
      private field_copier, private record_size_policy
{
public:
    template <typename type>
    operator type() const
    {
        assert(sizeof(type) <= record_size_policy::get_record_size());
        static_assert(std::is_arithmetic<type>::value || std::is_enum<type>::value ||
            std::is_pointer<type>::value || std::is_same<type, std::nullptr_t>::value,
            "Unsupported value type");
    
        type value;
        field_copier::read(m_data, &value);
        return value;
    }
    template <typename type, bool is_const2 = is_const,
              typename = std::enable_if_t<!is_const2>>
    binary_record_reference& operator=(type value)
    {
        assert(sizeof(type) <= record_size_policy::get_record_size());
        static_assert(std::is_arithmetic<type>::value || std::is_enum<type>::value
                      || std::is_pointer<type>::value
                      || std::is_same<type, std::nullptr_t>::value,
                      "Can only access arithmetic and enum values");
    
        field_copier::write(value, m_data);
        return *this;
    }
};

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

Применение

Система, ради которой писалась данная обёртка, оперирует пакетами двоичных данных, состоящими из двух частей: данных фиксированного размера и данных переменного размера.

Часть фиксированного размера организована как последовательность 64-битных полей. Как правило, одно поле содержит одно примитивное значение размером до 64 бит (незанятые байты игнорируются). Единственное исключение - массивы фиксированного размера, элементы которых располагаются в стык и могут занимать более одного поля: так, массив из пяти 16-битных значений займёт два 64-битных поля, внутри которых первые 80 бит содержат значения, а оставшиеся 48 бит не используются.

Данные динамического размера используются для передачи контейнеров произвольной длины и содержат элементы этих самых контейнеров, упакованные без дырок. Ссылки на такие контейнеры размещаются в части фиксированного размера в виде двух 64-битных полей: количества элементов и адреса.

Итераторы, служащие для чтения данных, определены так:

using handle_type = std::uint64_t;
using pack_field_const_iterator = binary_record_iterator<void,
        local_or_network_field_copier, fixed_record_size<sizeof(handle_type)>, true>;
using dynamic_data_const_iterator = binary_record_iterator<void,
        local_or_network_field_copier, runtime_record_size, true>;
template <typename element_type>
using specialized_dynamic_data_const_iterator = binary_record_iterator<element_type,
        local_or_network_field_copier, fixed_record_size<sizeof(element_type)>, true>;

Алгоритмы чтения данных работают с базовым абстрактным типом пакета:

enum class dynamic_data_pointer : uint64_t;
class data_pack
{
public:
    virtual ~data_pack() = default;

    // Метод доступа к данным фиксированного размера
    virtual pack_field_const_iterator read_static_data(
        size_type field_count) const = 0;

    // Методы доступа к данным динамического размера
    virtual dynamic_data_const_iterator read_dynamic_data(
        dynamic_data_pointer pointer, size_t element_size,
        size_type element_count) const = 0;
    template <typename element_type>
    specialized_dynamic_data_const_iterator<element_type> read_dynamic_data(
        dynamic_data_pointer pointer, size_t element_count) const
    {
        return read_module_side_data(pointer, sizeof(element_type), element_count)
                   .specialize<element_type>();
    }
};

Аргументы field_count и element_count служат для проверки выхода за границы доступных данных.

Существует два типа пакетов. Первый описывает данные, размещённые в оперативной памяти: имеющие естественный порядок байтов и использующие значение указателя в качестве адреса динамических данных (dynamic_data_pointer). Второй описывает пакет, полученный по сети: данные имеют сетевой порядок байтов, а в качестве адреса динамических данных используется смещение от начала пакета.

Благодаря слоям абстракции, реализованным классами пакета и итератора, алгоритму чтения данных не нужно ничего знать об их происхождении. Следующая врезка демонстрирует чтение нескольких значений из пакета в структуру. Запись будет выглядеть аналогично.

struct data
{
    std::int32_t a;
    double b;
    std::string c;
};
data read_data_from_pack(const data_pack* pack)
{
    data result;
    size_t string_size;
    dynamic_data_pointer string_data_pointer;
    auto static_data = pack->read_static_data(4);
    static_data.read(&result.a).read(&result.b); // Чтение цепочкой вызовов
    if (!static_data.read_length(&string_size))
        throw std::bad_alloc(); // Длина строки не помещается в наш size_t
    string_data_pointer = *static_data++; // Чтение в стиле итератора
    auto string_data_begin = pack->read_dynamic_data<char>(string_data_pointer,
        string_size);
    result.c = std::string(string_data_begin, string_data_begin + string_size);
    return result;
}

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

Удобство от работы с такими "итераторами по void*" становится более очевидным при написании обобщённого кода, не привязанного к конкретным типам. Например, следующий пример извлекает из пакета последовательность полей произвольных типов и передаёт их некому функтору:

template <typename cpp_type, typename = void>
struct type_traits;
template <typename cpp_type>
struct type_traits<cpp_type, std::enable_if_t<std::is_arithmetic<cpp_type>::value ||
    std::is_enum<cpp_type>::value>>
{
    static constexpr size_type field_count = 1;
    static cpp_type extract_value(data_pack*, pack_field_const_iterator position)
    {
        return static_cast<cpp_type>(*position);
    }
};
template <>
struct type_traits<std::u16string, void>
{
    static constexpr size_type field_count = 2;
    static std::u16string extract_value(const data_pack* pack,
        pack_field_const_iterator position)
    {
        size_t size;
        if (!position.read_length(&size))
            throw std::bad_alloc();
        if (size == 0)
            return std::u16string();
        module_pointer pointer;
        position.read(&pointer);
        auto data = pack->template read_dynamic_data<char16_t>(pointer, size);
        if (!data)
            throw invalid_data_pack();
        return std::u16string(data, data+size);
    }
};
template <typename... cpp_types>
struct argument_sequence_handler;
template <typename first_type, typename... next_types>
struct argument_sequence_handler<first_type, next_types...>
{
    using next_handler = argument_sequence_handler<next_types...>;
    using current_traits = type_traits<first_type>;
    template <typename callback_type, typename... extracted_arguments>
    static auto extract_and_invoke(data_pack *pack, pack_field_const_iterator input,
        callback_type callback, extracted_arguments&&... arguments)
    {
        first_type current_argument = current_traits::extract_value(pack, input);
        return next_handler::extract_and_invoke(pack, input +
              current_traits::field_count, callback, arguments..., current_argument);
    }
};
template <>
struct argument_sequence_handler<>
{
    template <typename callback_type, typename... extracted_arguments>
    static auto extract_and_invoke(data_pack*, pack_field_const_iterator,
        callback_type callback, extracted_arguments&&... arguments)
    {
        return callback(argunents...);
    }
};

Теперь шаблон argument_sequence_handler можно использовать для передачи в функтор произвольного числа аргументов произвольных типов, извлечённых из пакета:

auto static_data = pack->read_static_data(4);
auto const concatenated = argument_sequence_handler<std::u16string, std::u16string>::
    extract_and_invoke(pack, static_data, std::plus<std::u16string>());

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

Таким образом, удалось добиться разделения обязанностей между несколькими классами:

1. Класс binary_record_iterator отвечает за перемещение по байтовым последовательностям и за предоставление высокоуровневого интерфейса доступа к ним.

2. Стратегии копирования значений отвечают за доступ к данным и конверсию порядка байтов при необходимости.

3. Стратегии размера поля следят за упаковкой данных с дырками или без дырок.

4. Классы, производные от data_pack, отвечают за хранение данных и получение итераторов на них, а также сообщают итератору, какой порядок байтов используется в конкретном пакете.

5. Класс type_traits отвечает за чтение и запись конкретных типов, получая всю необходимую информацию о расположении данных от пакета и argument_sequence_handler.

6. Наконец, argument_sequence_handler берёт на себя работу по упорядочению работы с отдельными значениями, закодированными в последовательности.

В нашем проекте данный подход используется при взаимодействии модулей с ядром, а также при передаче пакетов данных по сети. Это позволяет расширять API взаимодействия (добавлять новые последовательности полей) без раздувания кода - простой специализацией соответствующих шаблонов. Помимо примитивных типов и строк, система позволяет обмениваться массивами фиксированного и динамического размера, а также дескрипторами объектов. Также планируется добавить поддержку структур.

Ссылки

• Основные классы итератора

• Стратегии копирования полей и размера записи

• Пакеты данных: раз, два, три

• Обработчик конкретных типов стороны ядра и стороны модуля

• argument_sequence_handler стороны ядра и стороны модуля

• Пример теста, много оперирующего описанными итераторами