Рассмотрим STL unordered_map. Один и тот же класс шаблона используется как для хеш-таблиц, генерируемых во время выполнения, так и для хеш-таблиц, состоящих из значений констант времени компиляции. Хотя в последних версиях C ++ добавлена поддержка constexpr, она не распространяется на более сложные операции, включающие свободное хранилище, поэтому построение хеш-таблицы из констант времени компиляции должно все же происходить во время выполнения, что делает его столь же дорогим, как и создание любой другой хеш-таблицы в во время выполнения.
В идеале идеальный компилятор должен видеть это и предварительно оценивать конструкцию хеш-таблицы во время компиляции и встраивать ее непосредственно в программу.
Это заставило меня задуматься о ретрокомпьютерах и микроконтроллерах, которые, по-видимому, написали бы свое программное обеспечение на C или C ++, учитывая стоимость разработки сборки: эти среды часто имеют ограниченную оперативную память, но много ПЗУ, и такие структуры данных в памяти (такие как unordered_map), конечно, может быть предварительно сгенерирован и сохранен в ПЗУ все во время компиляции.
Как уже упоминалось, язык C ++ не поддерживает это для нетривиальных constexpr. Я понимаю, что вы могли бы взломать это вместе, предполагая, что вы можете основать свою сложную структуру данных на типе массива или уменьшить ее до constexpr - или записать все это в сборке и вручную установить каждый байт структуры в hex-редакторе и надеюсь, что оно соответствует представлению компилятора ваших struct типов (например).
Как это делается сегодня? И как это было сделано во времена 16-битных и 32-битных игровых приставок, где такты ОЗУ и ЦП были выше? Я особенно заинтересован в том, чтобы узнать об играх на основе ROM-картриджей, где структуры сразу доступны в виде необработанной памяти.