Непостоянный параметр для шаблонного класса

Question

У меня есть шаблонный класс от API, который создается с чем-то вроде этого.

BitField объект;

Проблема в том, что переменная длины известна только во время выполнения.

ошибка: «длина» не может появляться в константном выражении -> это сообщение об ошибке

Есть предложения?

Answer 1

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

Один из способов обойти это, если вы знаете верхнюю границу для размера вашего набора битов и используете эту константу для вашей шаблонной структуры набора битов.Если верхняя граница неприемлемо велика, вам придется использовать другую структуру данных, похожую на вектор, который имеет динамический размер.

Answer 2

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

Answer 3

Это зависит от степени гибкости, которая вам нужна. Если вы имеете дело с небольшим набором сценариев, вы можете определить константы для своих возможностей и создать условные экземпляры.

РЕДАКТИРОВАТЬ: Спасибо Джон, нет фактического обоснования для #define более static const. Я смущен, что мой C показывает. Может быть, люди поверят, что это была неисправность клавиатуры.

...
static const int  8BIT = 8;
static const int 16BIT = 16;
static const int 32BIT = 32;
...
if( someDynamicCriteria == 8BIT )
{
    ...
    BitField<8BIT> object;
    ...
}
else if( someDynamicCriteria == 16BIT )
{
    ...
    BitField<16BIT> object;
    ...
}
else if( someDynamicCriteria == 32BIT )
{
    ...
    BitField<32BIT> object;
    ...
}
else
{
    // Unexpected case, error and exception handling
}

Очевидно, это становится невероятно быстрым. Это очень процедурный подход, и если ваша логика должна быть действительно динамичной, этот вид фальсификации быстро теряет свою ценность.

EDIT: Позвольте мне быть явно очевидным. Это подход, если вы действительно привязаны к этому конкретному API и структуре данных, а набор случаев, которые вам нужно обработать, невелик. Другими словами, если «использовать что-то другое» (что, честно говоря, лучший ответ) просто не будет работать.

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