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


В чем проблема-то? Единственный валидный юзкейз reinterpret_cast между разными типами это каст к массиву байт (или void*) и обратно.
Компилятор знает что вон тот char buffer[] потенциально может алиаситься с вот этим указателем и сгенерит менее производительный код.
placement new как раз подпадает под это - буфер чаров может алиаситься (и делает это) с указателем на произвольный T.
А вот любые другие типы (например int* в double*) алиаситься не могут.

Ну или более сложный пример, вы знаете что на вашей платформе sizeof(bool) == sizeof(int8_t) (ну или char).
Значит вы можете сделать
?

Это UB, в общем случае нельзя делать reinterpret_cast между unrelated типами.

https://en.cppreference.com/w/cpp/language/reinterpret_cast


Компилятор предполагает что 2 ссылки/указателя на различные типы не могут ссылаться не одну область памяти (strict alias rule) и строит на этом оптимизации.
reinterpret_cast ломает это предположение - если компилятор тупенький и не оптимизирует, то это будет работать, если умный, то сломается. UB.

Это UB

хз куда вы смотрели

https://doc.qt.io/qt-6/qtcore-changes-qt6.html#stability-of-references

хэш (обычно) это массив линкед-листов. при реаллокации массива, внезапно, адреса (и ссылки на элементы) нодов линкед листов не меняются - эту гарантию даёт, например, std::unordered_map.
можно действительно хэш реализовать другими способами, и тогда при раллокации адреса могут поехать, но в qt5 он был старым-добрым массивом линкед-листов и давал гарантию при insert'e (по крайней мере, оно работало на практике)
Но как минимум странно имея имплементацию "по стандарту" менять ее на другую которую захотела левая пятка, поломав кучу кода.
При переходе на qt6 код ломается, и самое простое решение - выкинуть QHash нафиг и использовать std::unordered_map.


Просто ваши задачи требуют неадекватного количества времени чтобы понять вообще в чем задача - требования меняются каждую страницу потому что вы их "забыли" указать, но предложенное решение им (конечно же!) не удовлетворяет.

Вздох.
std::vector::reserve ?

Ну кутешные контейнеры пишут такие же специалисты как те которые в итераторах не могут разобраться=)
В Qt6 например QHash не обеспечивает стабильность ссылок при вставке что ломает тонну кода.
Вы читайте cppreference - там требование к T чтобы он был default-constructible для operator[]. Интересно, зачем надо default-constructible кроме как чтобы позвать T() (подсказка - int a; дефолт ктор не зовет)

Кутешные контейнеры тут ни при чем - если элемента нет, вставляется default-constructed value, что для int'а 0 по стандарту. default-constructed value != uninitialized variable. Но это же букварь читать надо, тонкости языка знать, это не циклы с индексами писать=)


Ну это действительно софистика, потому что исходный код считал с нуля но зачем-то делал 3 лукапа.

придется почитать букварь и выяснить что operator[] таки возвращает ссылку

ну вообще это просто


но это уже надо знать про то что operator[] создает default-constructed T - это же не циклы с индексами писать, это справочники читать надо

Я не перегибаю, практика показывает, что люди, не знающие итераторов также не знают что operator[] возвращает ссылку (которую можно менять) или что такое explicit.

а потом я вычищаю из кода такое

Ну не очень ясно, мне кажется я все равно пользуюсь подобием.
Можно достроить аналогичный треугольник, скажем, справа, получим параллелограмм.
Дальше можно заметить, что если перекинуть "правый" кусок (треугольник) параллелогамма налево, то получим прямоугольник размера вдвое больше исходного треугольника.
А дальше вопрос, чем можно пользоваться - то есть как вычислить высоту и ширину.
С высотой просто - это 6 + 4 (высота левого большого треугольника).
С шириной хуже - надо понять что правые треугольники равнобедренные, а значит ширина правого куска тоже 3. Слева надо учесть что катеты относятся как 2 к 1 (но это же подобие?) и что ширина левого кусочка - 1.
Итого (6 + 4) * (1 + 2 + 6 + 3 + 3) / 2 = 75

upd: игнорируйте, фигню написал

О, я много на этом боли прочувствовал. До сих пор не пофиксили?