Контейнерные классы STL в скомпилированном коде UEFI
Недавно, изучая UEFI (предложенную замену BIOS), я попытался написать кое-что и скомпилировать с использованием EDK2. Идентификаторы должны были сгенерировать двоичный файл .EFI, который я могу запустить при входе в оболочку UEFI. Я был в состоянии сделать это. В совершенстве!
Теперь мой код использует чистый стиль C (в основном отсутствуют средства C ++, например, классы, конструкторы, виртуальные и классы контейнеров STL). Мне было интересно, смогу ли я использовать контейнерные классы STL (например, строки, векторы, хеш-карты) и все еще иметь возможность компилировать и запускать мой .EFI для UEFI?
Я немного исследовал и нашел много разочарований! В основном то, что я собрал, было:
- UEFI тесно связан с C. Реализации с открытым исходным кодом не поддерживают C ++
- новый и удалить не поддерживается.
- Генерация vtable зависит от компилятора, поэтому сгенерированный код не переносим
Кроме того, на этом сайте можно было многому научиться:
UEFI Программирование
Но, к сожалению, я остался в замешательстве!
Мой вопрос заключается в том, что я могу использовать классы STL (std :: string / std :: vector / std :: map) в своем коде и скомпилировать его, используя EDK2 для среды UEFI?
Я был бы признателен, если бы кто-нибудь указал мне решение / направление для поиска. Прямо сейчас, единственная опция, с которой я работаю, это одна C-реализация для контейнеров, найденных здесь:
UTHash реализация
Есть ли способ обойти?
Решение
Проблема не в памяти или vtable. UEFI имеет эффективное динамическое распределение памяти. И новые и удалить можно реализовать. Как и vtable, внутренне это просто обычная структура C! Проблема в том, что STL Троу исключения. И исключения зависят от платформы / ОС. В исключениях Windows STL ниже используется SEH (Структурная обработка исключений), которая зависит от ОС и тесно связана с внутренними потоками. В UEFI такого механизма нет, но его можно реализовать. Хотя это очень нетривиальная задача.
Другие решения
Пункт 2 не должен быть серьезной проблемой. Опора на new а также delete в основном через std::allocatorаргумент по умолчанию для каждого шаблона контейнера. Но это только по умолчанию. Предоставьте свой собственный распределитель (используя любое доступное распределение памяти в UEFI), и у вас будет хороший шанс заставить его работать.
Вряд ли ваша реализация STL использует vtables в любом случае, так что 3 также не имеет большого значения. Тем не мение, <iostream> будет другое дело.