Переключатель C++ не скомпилирует с внешне определенной переменной, используемой в качестве случая

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

Я не могу воспроизвести это на тривиальном примере с помощью VC ++ 2008:

test.cpp:

extern const int n;
int main() {
    switch (0) {
    case n: break;
    }
}

test2.cpp:

extern const int n = 123;

скомпилировать с:

cl.exe test.cpp test2.cpp

вывод:

test.cpp (4): ошибка C2051: выражение case не константа

VC ++ правильный, а g ++ неправильный. Метка case должна быть интегральным константным выражением (§6.4.2 / 2), а константная переменная целочисленного типа, инициализированная константным выражением, является константным выражением (§5.19 / 1).

Edit: в основном для Павла и его предложения о возможном DR. §5.19 / 2 был полностью переписан. C ++ 0x добавляет совершенно новую концепцию constexpr , которая значительно расширяет то, что считается константным выражением. Например, в соответствии с текущим стандартом что-то вроде:

int x() { return 10; }
const int y = x();

y не является постоянным выражением. Мы все легко можем видеть, что он (косвенно) инициализируется литералом 10 , но компилятор по-прежнему не может разрешить его как постоянное выражение. По новому стандарту это ' Можно будет обозначить x () как constexpr , а y будет постоянным выражением.

Как это сформулировано в N2960, §5.19 / 2 говорит, что выражение является постоянным выражением, если оно не использует что-либо из следующего списка. Затем он дает список длиной в страницу, но использование переменной const , которая не инициализирована в текущем модуле компиляции, не кажется одним из них. [Изменить: см. Ниже - прочитав выпуск 721 CWG, я передумал.]

Что касается VC ++, то есть правильности, а g ++ - неправильности, я имел в виду только этот очень конкретный аспект. Нет никаких сомнений в том, что оба «неправильны», если вы говорите о правильности каждой части стандарта. Я сомневаюсь, что кто-то вообще работает над реализацией экспорта для любого из них.

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

Редактировать: Я немного поискал и обнаружил проблему 721 основной рабочей группы. Вопрос Джейма довольно близко соответствует рассматриваемому («Однако для этого не требуется, как предположительно должно, чтобы инициализация происходила в той же единице перевода и предшествовала константному выражению ...»). Предлагаемое постановление добавляет фразу: «... с предшествующей инициализацией ...». По крайней мере, когда я ее читал, это означает, что комитет согласился с тем, что в соответствии с текущим стандартом код должен быть принят, но в соответствии с новым стандартом это не разрешено.

Эта формулировка была согласована в июле этого года, но не (пока?) не появился в N2960, который, я считаю, является самым последним проектом C ++ 0x.

Компилятор MS здесь немного шалит. Когда вы компилируете инициализацию константы и оператор case с использованием константы в одном модуле компиляции, она вычисляет значение константы во время компиляции.

Как только вы пытаетесь использовать extern const вне модуля компиляции, в котором он инициализирован (т. е. файл cpp, содержащий инициализацию, или любой из файлов, которые он включает), компилятор отключит примерно такую ​​же ошибку. Фред Ларсон прав, компилятор не должен знать постоянное значение до времени компоновки, и, следовательно, оно не должно быть приемлемым в качестве константы переключения, это просто компилятор MS немного обманывает.

Решение вашего проблема заключается в использовании макросов, есть ли причина, по которой вы не

Вот более простой тест:

test_int.cpp:

const int test_int = 10;

main.cpp:

#include <iostream>
using std::cout;
using std::endl;

extern const int test_int;

int main() {
    cout << test_int << endl;
    return 0;
}

В G ++ я получаю неопределенную ссылку. Однако то же самое в C работает. Согласно http://gcc.gnu.org/ml/gcc/2005-06/msg00325.html , переменная const неявно имеет внутреннюю связь в C ++. Похоже, что это не так в C.

Я использую "gcc (SUSE Linux) 4.3.2" и имею похожий эффект, но это все еще немного странно.

Мои определения:

namespace operations{
   const cOpDummy OpDummy();
   const cInitOperator InitOperator();
};

const unsigned long ulNumberOfOperations = 2;

const cOperation * arrayOperations[] = {
   & (operations::OpDummy),
   & (operations::InitOperator)
};

А объявления extern в другом файле:

extern const unsigned long ulNumberOfOperations;
extern const cOperation * arrayOperations[];

Забавная вещь: Компилятор выдает только для "ulNumberOfOperations" "undefined reference to ulNumberOfOperations", но с "arrayOperations[]" все в порядке. Мой обходной путь - объявить "ulNumberOfOperations" не константой.