C++ reinterpret_cast - это всегда будет работать правильно?

Question

Я написал класс MyString и MyStringConst. Теперь мне нужно время от времени передавать MyString как MyStringConst, следовательно, перегружать оператор переноса. Я написал это

MyString::operator const MyStringConst &() const 
{ 
    return reinterpret_cast<const MyStringConst &>(*this); 
} 

MyString имеет эти данные

char * str; 
int length; 
volatile int hashCode; 
int bufferSize; 

MyStringConst имеет эти данные

const char * c_str; 
int length; 
volatile int hashCode; 

Плюс есть некоторые методы, которые в обеих строках можно пересчитать хэш-код.

Правильно ли это код. Я тестировал его на MSVC 2013, и он работает правильно, но я понятия не имею, можно ли его использовать в производственном коде, который может быть скомпилирован с помощью другого компилятора.

Answer 1

Общая исходная последовательность элемента данных различна, и C++ не дает никаких гарантий относительно макета в этом случае, даже если типы отличаются только квалификацией const. В противном случае гарантии для union s будут фактически означать, что типы должны иметь общий макет, если они являются стандартными типами макета (согласно примечанию в пункте 9.5 [class.union]).

На практике я бы ожидал, что два типа выложены одинаковыми и что работает reinterpret_cast, но нет стандарта. Основываясь на ваш комментарий MyStringConst просто держит указатель на строку, то есть, вместо преобразования в ссылки, я бы просто вернуть соответствующим образом построены MyStringConst и не полагаться на непредсказуемое поведение:

MyString::operator MyStringConst() const { 
    return MyStringConst(str, length); 
} 

Объект MyString еще должен жить до тех пор, пока результат преобразования, но это не отличается от случая с использованием reinterpret_cast.

BTW, volatile на hashCode не рекомендуется: единственный эффект, который у него будет, заключается в замедлении работы программы. Я предполагаю, что вы пытаетесь использовать его для достижения синхронизации между потоками, но в C++ volatile не помогает в этом: вы получаете гонку данных при записи элемента в одном потоке, к которому также обращаются несинхронизированные в другом потоке. Вы наделили бы членов

std::atomic<int> hashCode; 

вместо этого.