Имея статические константные переменные с GCC 3.3 аналогично GCC 3.4

Question

При использовании г ++ 3.4.6 (с ЛД 2.15.92.0.2), можно написать:

class ConstantContainer { 
public: 
    static const uint16_t MyConstant1 = UINT16_C(0x4321); 
    static const uint32_t MyConstant2 = UINT32_C(0x87654321); 
    static const uint64_t MyConstant3 = UINT64_C(0xF0E1D2C3B4A59687); 
    static const double MyConstant4 = 1.0/4.0; 
}; 

и использовать ConstantContainer::MyConstant1 и другие почти везде, как заменяют подменю для замеченных литералов, за исключением инициализации других констант.

Однако при использовании г ++ 3.3.6 (с л.д. тех же версий 2.15.92.0.2, хотя и не такие же бинарное и дистрибутив), код компилируется нормально, тоже, но сшивание не может в некоторых случаях из-за чтобы неразрешенной ссылки на какой-либо точке «константа» используется:

g++ -o myapp module1.o module2.o ... main.o 
moduleN.o(.text+0x59e): In function `BlahBlah(const FooBar&)': 
: undefined reference to `ConstantContainer::MyConstant1' 

Я не мог понять, что являются уникальные особенности, которые провоцируют такое поведение. Например, несовместимый случай может быть таким простым:

class GraphConversionState { 
public: 
    struct NodeIndex { 
    public: 

     typedef CxxStd::uint32_t ValueType; 
     ValueType Value; 

     class ValueSpecial { 
     public: 
      static CxxConstExpr ValueType 
       Unknown = UINT32_C(0xFF000000), 
       Isolated = UINT32_C(0xFF111111), 
       Connected = UINT32_C(0xFFCCCCCC); 
     }; 
    }; 
}; 

I. e. существует только небольшая группа статических константных членов типа uint, но они не могут рассматриваться как именованные литералы; Между тем, в других случаях даже значения с плавающей запятой прекрасны. Единственное очевидное различие - это уровень уровня (вложенность классов), но это не является реальной причиной в общем случае с упрощенными примерами.

Очевидным решением является превратить вышеупомянутый класс в монстра:

class ConstantContainerType { 
public: 
    uint16_t MyConstant1; 
    uint32_t MyConstant2; 
    uint64_t MyConstant3; 
    double MyConstant4; 
    ConstantContainerType() : 
     MyConstant1(UINT16_C(0x4321)), 
     MyConstant2(UINT32_C(0x87654321)) 
     MyConstant3(UINT64_C(0xF0E1D2C3B4A59687)) 
     MyConstant4(1.0/4.0) 
     { } 
}; 
static const ConstantContainerType ConstantContainer; 

// in ConstantContainer.cpp: 
const ConstantContainerType ConstantContainer; 

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

Итак, я задавался вопросом: каковы точные правила, применяемые GCC 3.3 и выше для обработки некоторых статических константных объявлений POD как постоянных определений?

Answer 1

Либо вы можете определить его в другом месте,

class ConstantContainer { 
public: 
    static const uint16_t MyConstant1; 
    static const uint32_t MyConstant2; 
}; 
ConstantContainer::MyConstant1 = UINT16_C(0x4321); 
ConstantContainer::MyConstant2 = UINT32_C(0x87654321); 

или сделать второй уборщик, объявляя членов, как константы.

class ConstantContainer { 
public: 
    const uint16_t MyConstant1; 
    const uint32_t MyConstant2; 
    ConstantContainer(uint16_t foo, uint16_t bar) 
     :MyConstant1(foo), MyConstant2(bar) 
    {} 
}; 

Answer 2

старый трюк все еще работает:

class ConstantContainer { 
public: 
    enum { MyConstant1 = UINT16_C(0x4321) }; 
    enum { MyConstant2 = UINT32_C(0x87654321) }; 
}; 

Конечно, если вы хотите фактические объекты типа uint16_t/uint32_t, они должны где-то жить.

Answer 3

Просто используйте пространство имен вместо злоупотребляя классов так:

namespace ConstantContainer { 
    uint16_t const MyConstant1 = UINT16_C(0x4321); 
    uint32_t const MyConstant2 = UINT32_C(0x87654321); 
} 

Кроме того, константы в области видимости пространства имен имеют внутреннюю связь по умолчанию (например, статических объектов на уровне пространства имен), поэтому вы можете объявить и определить их в файл заголовка без риска нарушений ODR.