• XSS.stack #1 – первый литературный журнал от юзеров форума

Статья Немножко Compile-Time вычислений

PlebsoVata

RAID-массив
Пользователь
Регистрация
05.10.2019
Сообщения
87
Реакции
34
Начал разбираться с compile-time вычислениями в С++. Написал такой код для хэширования(crc32) строчки:
C++:
constexpr inline size_t str_bytes(const char* str)
{
    size_t val = 0;
    while (*str != NULL)
        ++val, ++str;
    return val;
}

static uint32_t constexpr crc32_tab[] = {
    0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419, 0x706af48f,
    0xe963a535, 0x9e6495a3,    0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
    0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, 0x1db71064, 0x6ab020f2,
    0xf3b97148, 0x84be41de,    0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
    0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,    0x14015c4f, 0x63066cd9,
    0xfa0f3d63, 0x8d080df5,    0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
    0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,    0x35b5a8fa, 0x42b2986c,
    0xdbbbc9d6, 0xacbcf940,    0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
    0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423,
    0xcfba9599, 0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
    0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,    0x76dc4190, 0x01db7106,
    0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
    0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, 0x7f6a0dbb, 0x086d3d2d,
    0x91646c97, 0xe6635c01, 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
    0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6, 0x12b7e950,
    0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
    0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, 0x4adfa541, 0x3dd895d7,
    0xa4d1c46d, 0xd3d6f4fb, 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
    0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9, 0x5005713c, 0x270241aa,
    0xbe0b1010, 0xc90c2086, 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
    0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 0x59b33d17, 0x2eb40d81,
    0xb7bd5c3b, 0xc0ba6cad, 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
    0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683, 0xe3630b12, 0x94643b84,
    0x0d6d6a3e, 0x7a6a5aa8, 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
    0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe, 0xf762575d, 0x806567cb,
    0x196c3671, 0x6e6b06e7, 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
    0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5, 0xd6d6a3e8, 0xa1d1937e,
    0x38d8c2c4, 0x4fdff252, 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
    0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60, 0xdf60efc3, 0xa867df55,
    0x316e8eef, 0x4669be79, 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
    0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, 0xc5ba3bbe, 0xb2bd0b28,
    0x2bb45a92, 0x5cb36a04, 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
    0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a, 0x9c0906a9, 0xeb0e363f,
    0x72076785, 0x05005713, 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
    0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, 0x86d3d2d4, 0xf1d4e242,
    0x68ddb3f8, 0x1fda836e, 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
    0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c, 0x8f659eff, 0xf862ae69,
    0x616bffd3, 0x166ccf45, 0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
    0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db, 0xaed16a4a, 0xd9d65adc,
    0x40df0b66, 0x37d83bf0, 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
    0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, 0xbad03605, 0xcdd70693,
    0x54de5729, 0x23d967bf, 0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
    0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
};

constexpr inline uint32_t crc32_impl(uint32_t prevCrc, const char* str, size_t size)
{
    return !size ? prevCrc : crc32_impl((prevCrc >> 8) ^ crc32_tab[(prevCrc ^ *str) & 0xff], str + 1, size - 1);
}

constexpr inline uint32_t crc32(const char* str)
{
    return crc32_impl(0xffffffff, str, str_bytes(str)) ^ 0xffffffff;
}

template <typename Holder>
constexpr unsigned HashCalc(Holder str_holder)
{
    constexpr auto str = str_holder();
    constexpr unsigned hash = crc32(str);
    return hash;
}

template <typename Holder>
constexpr unsigned HelperFunc(Holder hash_holder)
{
    constexpr auto hash = hash_holder();
    return hash;
}


#define Lambda(str) HelperFunc( [] { return HashCalc([](){ return str; }) ; } )
#define Lambda_No_Helper(str) HashCalc([](){ return str; })
Это мой main:
C++:
int main()
{
    constexpr auto hashi = Lambda("UEFI");
    auto NewHash = Lambda("invisible string");
    auto NewHash1 = Lambda_No_Helper("visible string");

    return NewHash;
}
Я хочу посчитать хэш строчки в компайл-тайме, чтобы сама строка в бинарнике вообще не оставалась.
Но опять же constexpr не дает гарантий что все выполнится в компайл-тайме, он только попробует, а если не сможет, то все будет выполняться в ран-тайме, компиляторы могут оставить на ран-тайм большую рекурсию, даже если теоретически могут посчитать результат.

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

В первом случае у меня генерится одна mov инструкция
constexpr auto hashi = Lambda("UEFI");

Во втором случае дохуя инструкций, наша лямбда сохраняется как объект в памяти, но хэш посчитан, самой строчки в памяти нет и наша переменная не constexpr
auto NewHash = Lambda("invisible string");
Вот сгенеренный студией асм:
Код:
 xor         eax,eax 
 mov         byte ptr [ebp-101h],al 
 movzx       ecx,byte ptr [ebp-101h] 
 push        ecx 
 call        HelperFunc<<lambda_e0a925145e7fb86677c7a8381733ecbb> > (0C3B710h) 
 add         esp,4 
 mov         dword ptr [NewHash],eax
Внутри HelperFunc куча мусора, но строка не хранится, сам хэш не считается, он уже посчитан в компайл-тайме и там снова по сути 1 mov инструкция

В третьем случае почему-то какой-то пиздец, есть лямбда, только другая, строчка в памяти остается(можно проверить в дизасме студии или банальном поиском в бинарнике через HxD), но при этом сам хэш посчитан в компайл-тайме(1 mov инструкция).
auto NewHash1 = Lambda_No_Helper("visible string");
Вот сгенеренный студией асм:
Код:
xor         eax,eax 
 mov         byte ptr [ebp-10Dh],al 
 movzx       ecx,byte ptr [ebp-10Dh] 
 push        ecx 
 call        HashCalc<<lambda_eb46af9cfe8c58dca019aa0153dd5821> > (0C3B6B0h) 
 add         esp,4 
 mov         dword ptr [NewHash1],eax
Вот что внутри HashCalc:
Код:
    //constexpr auto str = str_holder();
 mov         dword ptr [str],offset string "visible" (0AE4C18h) 
    //constexpr unsigned hash = crc32(str);
 mov         dword ptr [hash],25B2888Fh 
    //return hash;
 mov         eax,25B2888Fh
Например если компилировать с оптимизациями, то большинство проблем с хэшированием строк уйдут, объекты лямбд в силу их дальнейшего неиспользования в ран-тайме также уйдут, строчки не будут хранится, останется только хэш.

Но есть еще другой подход, реализацию которого я еще не смог придумать для нормальной работы со строчками и их хэшированием, поэтому покажу на примере чисел Фибоначи.
C++:
// No-Constexpr meta programming approach
template<int I>
struct Fib
{
    static const int val = Fib<I - 1>::val + Fib<I - 2>::val;
};

template<>
struct Fib<0>
{
    static const int val = 0;
};

template<>
struct Fib<1>
{
    static const int val = 1;
};

// Constexpr meta programming approach
template<int  N>
constexpr int fibonacci() { return fibonacci<N - 1>() + fibonacci<N - 2>(); }
template<>
constexpr int fibonacci<1>() { return 1; }
template<>
constexpr int fibonacci<0>() { return 0; }


int main()
{
    auto Fib_0 = Fib<46>::val;
    constexpr auto Fib_1 = Fib<40>::val;

    auto fibonacci_0 = fibonacci<46>();
    constexpr auto fibonacci_1 = fibonacci<26>();

    return 0;
}
Здесь 2 подхода, первый без constexpr, на шаблонных структурах, второй на constexpr шаблонных функциях
Сразу скажу что первый подход обходит второй по всем пунктам.

Во-первых функция fibonacci<>() не может посчитать последовательность после 27 числа. max_input = 26.
То есть такая строчка просто не скомпилируется(по крайней у меня и с компилятором от майков, а не клангом)
constexpr auto fibonacci_1 = fibonacci<27>();
Ошибка гласит что выражение не может преобразовано в константу(LOL).
При этом же в этой строке студия выдает предупреждение C26498, в котором говорится что наша функция constexpr, пометьте переменную fibonacci_0 как constexpr, если нужно вычисление в компайл-тайме, однако это невозможно, т.к. max_input = 26.
auto fibonacci_0 = fibonacci<46>();
Также стоит отметить, что наше 46 число фибоначи будет считаться очень долго и в ран-тайме, в отличие от первого подхода.

В первом же подходе все просто, в компайл-тайме все посчиталось и стоят две mov инструкции, вот асм код для main:
Код:
    //auto Fib_0 = Fib<46>::val;
 mov         dword ptr [Fib_0],6D73E55Fh 
    //constexpr auto Fib_1 = Fib<40>::val;
 mov         dword ptr [Fib_1],6197ECBh 

    //auto fibonacci_0 = fibonacci<46>();
 call        fibonacci<46> (08E192Eh) 
 mov         dword ptr [fibonacci_0],eax 
    //constexpr auto fibonacci_1 = fibonacci<26>();
 mov         dword ptr [fibonacci_1],1DA31h 

    //return 0;
 xor         eax,eax
А на этом мое сравнение заканчивается.
 
Кстати насчет static_assert, можно делать проверки до компиляции и проверять, что мы передаем валидную строку, а не nullptr например. Вот так можно переписать str_bytes, есть минусы, нам опять нужен холдер в виде лямбды и макрос соответственно, также компилятор будет говорить что наша ошибка внутри функции, а не в строчке, где мы написали STR_BYTES(nullptr), но все я думаю это очень удобно.
C++:
template <typename Holder>
constexpr inline size_t str_bytes_(Holder str_holder)
{
    constexpr const char* str = str_holder();
    static_assert(str != nullptr, "nullptr string not allowed");
    size_t val = 0;
    while (*(str + val) != NULL)
        ++val;
    return val;
}

#define STR_BYTES(str) str_bytes_([]{ return str; })

int main()
{
    STR_BYTES(nullptr);
    constexpr auto len =  STR_BYTES("some string");

    return 0;
}

Также огромным плюсом в случае с холдером является возможность подключения <string_view> библиотеки, начиная с С++17
Это нам даст возможность поиска в строке, находить подстроки, сравнивать, находить размер и много чего еще в компайл-тайме(почти), все члены функций string_view constexpr, так что с включенными оптимизациями, я думаю, кода точно будет не много и все действительно будет посчитано в компайл-тайме.
В итоге наш код может быть таким:
C++:
#include <string_view>
template <typename Holder>
constexpr inline size_t str_bytes_(Holder str_holder)
{
    constexpr const char* str = str_holder();
    constexpr std::string_view sv_str = str_holder();
   
    return sv_str.size();
}

#define STR_BYTES(str) str_bytes_([]{ return str; })

int main()
{
    constexpr auto len =  STR_BYTES("some string");

    return 0;
}
Также string_view не тянет за собой CRT(по крайней у меня) и в некоторых случаях может помочь оптимизировать код компилятору, так что его можно использовать в малваре, как и другие фичи С++ последних стандартов, которые не тянут за собой CRT, например фичи при работе с шаблонами и также structure binding
 


Напишите ответ...
  • Вставить:
Прикрепить файлы
Верх