Тупизна какая-то. Всегда меньшее в большее кастилось без проблем, теперь студия резко разучилась. Но через два каста подряд всё ещё можно.
Закомитил фикс. Непонятно почему, но теперь компилятор счастлив.
Тупизна какая-то. Всегда меньшее в большее кастилось без проблем, теперь студия резко разучилась. Но через два каста подряд всё ещё можно.
- void* - это как бы адрес, если туда пихают int, то половину адреса, вероятно, уже где-то сломали/потеряли, промотить молча опасно.
Это не так. Размер у них одинаковый, а смысл разный (тут указатель, а там число).
У меня в отладчике MSVC 2013
(void*)0xFFFFFFFF
даёт как раз 0x00000000ffffffff
.Указатель это то же самое целое число. Идеологически это может и разные вещи, но физически разницы никакой.
Вы смешиваете разные уровни абстракции. На архитектуре x86_64 указатель реализуется как адрес, который представляется числом. Своё предупреждение компилятор выдаёт на верхнем из этих уровней, поэтому про нижележащее число он в этот момент знать не хочет (и Вам не советует).
В x86 (void*)int давало то же самое битовое представление. В x64 - не то же самое.
Ну так вы литерал сначала к int приведите.
М-да, я как-то и забыл, что
0xFFFFFFFF
в int
не укладывается и поэтому имеет тип unsigned int
. В x86 адреса в short, как правило, не паковали.
Приведение к memsize никак не поменяет результат. int->uint64->void* == int->void*. Тогда уже надо требовать, чтобы число unsigned было, там проблем со знаком нет.DrKnS wrote: ↑Wed 05 Jul, 2017 11:51 Скользкая тема - это каст 32-битного типа в адрес, когда в зависимости от знака получаются сильно разные адреса.
Учитывая, что в x86 традиционно не заморачивались и пихали указатели куда попало - я их понимаю. Несмотря на то, что это вполне defined behaviour, лучше явно требовать сначала явного приведения к memsize-типу.
Естественно, он и не должен меняться.