Интерпретация переменной типа int как float

@Rybik001 · Регистрация: 10.06.2013

Студворк — интернет-сервис помощи студентам

C++
1
int a = 1143816535

Как мне получилось 693,0209351 во float?

@hoggy · 16.08.2021, 21:53

Сообщение от Verevkin

int a = 1143816535;
float *ptr = &a;
float f = *ptr;

Code
1
error: cannot convert ‘int*’ to ‘float*’ in initialization

Сообщение от Verevkin

float f = *(float*)&a;

UB

Code
1
warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]

Сообщение от Verevkin

U.a = 1143816535;

это вообще не скомпилируется.
наверное, ты имел ввиду:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <iostream>
 
union U
{
  int32_t a;
  float f;
};
 
int main()
{
    U v;
    v.a = 1143816535;
    std::cout << v.f;
}

несмотря на то, что на практике,
трюк с объединением прокатывает на всех топовых компиляторах,
тем не менее, формально, такой код содержит UB.

лично я не стал бы ставить на такой код свою карьеру.
зачем?
если можно просто написать корректный код

Добавлено через 6 минут

Сообщение от Verevkin

Я, например, сразу понял, что хотел автор - интерпретировать 4 байт

в старых версиях с++ такое было невозможно провернуть не налетев на UB

в новом с++ можно воспользоваться std::launder
и это - единственный легальный способ реинтерпретировать "теплое" как "мягкое"

C++
1
2
3
4
5
6
7
8
#include <iostream>
 
int main()
{
    int a = 1143816535;
    float& f = *std::launder(reinterpret_cast<float*>(&a));
    std::cout << f << '\n';
}

Verevkin · 16.08.2021, 21:55

Сообщение от hoggy

в старых версиях с++ такое было невозможно провернуть не налетев на UB

А как это можно смоделировать?

@Catstail · 16.08.2021, 21:58

Сообщение от TheCalligrapher

Оба варианта - грубейше неправильные.

- странно, что "грубейше неправильные" варианты тем не менее транслируются и успешно исполняются...

Невольно возникает вопрос: почему язык не запрещает подобные конструкции? Или конкретнее - почему их пропускает компилятор?

@hoggy · 16.08.2021, 22:00

Сообщение от Verevkin

А как это можно смоделировать?

ну вот например

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <iostream>
 
int foo( float *f, int *i ) { 
    *i = 1;               
    *f = 0.f;            
   return *i;
}
 
int main() {
    int x = 0;
    
    std::cout << x << "\n";   // Expect 0
    x = foo(reinterpret_cast<float*>(&x), &x);
    std::cout << x << "\n";   // Expect 0?
}

output:

Code
1
2
0
1

@TheCalligrapher · 16.08.2021, 22:06

Сообщение от Catstail

странно, что "грубейше неправильные" варианты тем не менее транслируются и успешно исполняются...

Странно, что в форуме по С++ (пусть даже "для начинающих"), приводят в качестве "аргумента" такой детский лепет, как "эти варианты транслируются и успешно исполняются", как будто не понимают, что в С и С++ ваше "транслируются и успешно исполняются" не значит вообще ничего. Неужели за весь период существования этого форума даже завсегдатаи не смогли усвоить таких элементаранызх понятий, как неопределнное поведение?

В очередной раз спрошу с нескрываемым удивлением: вот это вот "транслируются и успешно исполняются" - это такой троллинг? Или здесь все действиельно настольоко запущено?

Verevkin · 16.08.2021, 22:06

Сообщение от hoggy

ну вот например

Да я не про это. Я про "создать такие условия, чтобы мой код выдал неверный результат".

@TheCalligrapher · 16.08.2021, 22:07

Сообщение от Catstail

Невольно возникает вопрос: почему язык не запрещает подобные конструкции? Или конкретнее - почему их пропускает компилятор?

Рука-лицо... "Почему компилятор разрешает мне писать неправильные программы"?

@Catstail · 16.08.2021, 22:12

TheCalligrapher, нет это не троллинг. Это вопрос к системе типов. Что стоило просто запретить подобные преобразования - и не было бы проблем. Если Вы мне объясните это (и я пойму), то буду благодарен... Когда меня убеждают - я соглашаюсь.

А вот когда мне заявляют менторским тоном "Это так и никак иначе", а на вопрос "Почему?" отвечают "Потому", то я упираюсь. Мне кажется, это мое право.

@TheCalligrapher · 16.08.2021, 22:17

Сообщение от hoggy

в новом с++ можно воспользоваться std::launder

Нет, нельзя. Никакого отношения к прямой реинтерпретации std::launder не имеет. Требование std::launder<T> - по целевому адресу располагается именно объект типа T.

Добавлено через 4 минуты

Сообщение от Catstail

нет это не троллинг. Это вопрос к системе типов. Что стоило просто запретить подобные преобразования - и не было бы проблем.

Невозможно на стадии компиляции "запретить преобразования", когда их корректность в общем случае зависит от факторов времени выполнения.

Сообщение от Catstail

Если Вы мне объясните это (и я пойму), то буду благодарен... Когда меня убеждают - я соглашаюсь.
А вот когда мне заявляют менторским тоном "Это так и никак иначе", а на вопрос "Почему?" отвечают "Потому", то я упираюсь.

Тема strict aliasing здесь обсуждадась много раз, в деталях. Зачем начинать сказку про белого бычка сначала?

https://stackoverflow.com/ques... asing-rule
https://habr.com/ru/company/otus/blog/442554/

@hoggy · 16.08.2021, 22:19

Сообщение от TheCalligrapher

Нет, нельзя. Никакого отношения к прямой реинтерпретации std::launder не имеет. Требование std::launder<T> - по целевому адресу располагается именно объект типа T.

да, действительно.

@Catstail · 17.08.2021, 07:02

TheCalligrapher, понял. Спасибо.

@COKPOWEHEU · 17.08.2021, 10:12

Сообщение от hoggy

формально, такой код содержит UB.
лично я не стал бы ставить на такой код свою карьеру.

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

Сообщение от Verevkin

А как это можно смоделировать?

Сложно. Возможно, сломается на big/little endian, возможно с другим размером байта (стандарт дозволяет!) или еще при каких-то экзотических условиях.

Сообщение от Catstail

странно, что "грубейше неправильные" варианты тем не менее транслируются и успешно исполняются... Невольно возникает вопрос: почему язык не запрещает подобные конструкции? Или конкретнее - почему их пропускает компилятор?

Потому что С (а следом и С++) заточены под ручную оптимизацию. Если программист знает, что делает - не надо ему мешать.

Сообщение от hoggy

ну вот например

Чуть упрощу ваш код:

C
1
2
3
4
5
6
7
8
9
10
int func(int *arg){
  *arg = 2;
  return 3;
}
 
int main(){
  int x = 0;
  x = func(&x);
  printf("%i\n", x);
}

Ожидаемо x=3. К чему нужны извращения с reinterpret_cast и что вы вообще хотели продемонстрировать?

Сообщение от TheCalligrapher

как будто не понимают, что в С и С++ ваше "транслируются и успешно исполняются" не значит вообще ничего

Да все прекрасно понимают, что ваше "не значит ничего" не значит ничего. Если код транслируется и выполняется, то он транслируется и выполняется. И если он написан грамотно, то даже при наличии UB он продолжит транслироваться и выполняться как задумано, и им прекрасно можно пользоваться. Высокоуровневый ассемблер на то и высокоуровневый ассемблер чтобы давать возможность привязаться к особенностям конкретной платформы.

Добавлено через 7 минут

Сообщение от Catstail

Что стоило просто запретить подобные преобразования - и не было бы проблем.

Так проблем и нет. Собственно, это одно из применений union'ов - интерпретация одной и той же кучки битов как разные типы. Один пример я уже описал - вычисление обратного корня. Второй - разбиение переменной на байты:

C
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <stdio.h>
#include <stdint.h>
 
typedef union{
  uint32_t val_32;
  struct{
    uint8_t b1;
    uint8_t b2;
    uint8_t b3;
    uint8_t b4;
  };
}Bytes4;
 
int main(){
  Bytes4 val;
  val.val_32 = 0x12345678;
  printf("%.2X %.2X %.2X %.2X\n", val.b1, val.b2, val.b3, val.b4);
}

С некоторой натяжкой сюда же можно отнести систему событий в различных оконных системах вроде SDL или curses. Идентификатор события читается из наиболее общей структуры, и уже потом по нему идет каст к нужной. Но по определению TheCalligrapher, это все равно UB. Но, как обычно, крики "неправильный код! Не компилируется!" никого не волнуют. Код работает, люди им пользуются.

Verevkin · 17.08.2021, 10:17

Сообщение от COKPOWEHEU

Сложно. Возможно, сломается на big/little endian

А чего, big/little endian распространяется не на все типы, а только на некоторые?
Я вчера так и не смог придумать пример UB для union {uint32_t x; float y; }. Если у int сменить порядок байтов, то у float он тоже должен измениться, разве нет?

З.Ы. Хорошо, что я в своё время выбрал себе основным языком программирования язык со строгой типизацией.

@COKPOWEHEU · 17.08.2021, 10:27

Сообщение от Verevkin

Если у int сменить порядок байтов, то у float он тоже должен измениться, разве нет?

Не знаю. Но допускаю и такую возможность. Все-таки к байтам int'а можно обращаться по отдельности скажем для сложения, то float имеет смысл только как неделимая 32-битная сущность.

@DrOffset · 17.08.2021, 11:53

Сообщение от COKPOWEHEU

К чему нужны извращения с reinterpret_cast и что вы вообще хотели продемонстрировать?

Это код из этой статьи, там же все объяснено, зачем и чего код демонстрирует.

Добавлено через 19 минут

Сообщение от COKPOWEHEU

И если он написан грамотно, то даже при наличии UB он продолжит транслироваться и выполняться как задумано, и им прекрасно можно пользоваться. Высокоуровневый ассемблер на то и высокоуровневый ассемблер чтобы давать возможность привязаться к особенностям конкретной платформы.

У вас тут смешаны понятия implementation-defined behavior, unspecified-behavior и undefined-behavior.
Вся аргументация про высокоуровневый ассемблер и грамотный код справедлива только для первых двух понятий, но никак не для последнего.

Сообщение от COKPOWEHEU

Идентификатор события читается из наиболее общей структуры, и уже потом по нему идет каст к нужной. Но по определению TheCalligrapher, это все равно UB.

По его определению этот как раз не UB, потому что в этом случае по идентификатору мы точно понимаем что было записано при отправке события, и каст делаем именно к тому типу, который был записан. Т.е. тут нет type punning, и нет UB. Это применение union как раз является правильным во всех смыслах.
Кроме того, как было уже сказано, в языке С разрешен type punning через union, в языке С это не UB.
Кроме того, разработчики компиляторов С++ прекрасно знают, что трюк с реинтерпретацией через union очень популярен и в коде на С++, поэтому не реализуют никаких помех для его выполнения. Но это не делает код корректным, так же как не делает правильным забег через дорогу на красный свет, не смотря на то, что миллионы человек могут похвастаться, что с ними во время этого ничего не случилось.

Сообщение от COKPOWEHEU

крики

Не понятно почему аргументация к спецификации языка является "криками", ничего нового он не сказал, это все известно еще со времен C++98.
Можно или нельзя в конкретном проекте плевать на несоответствие кода спецификации (в части корректности) - это вообще отдельный вопрос, который тут не обсуждался даже.

@hoggy · 17.08.2021, 12:28

Сообщение от COKPOWEHEU

Чуть упрощу ваш код:

Сообщение от COKPOWEHEU

К чему нужны извращения с reinterpret_cast и что вы вообще хотели продемонстрировать?

а зачем ты его начал чуть упрощать,
если ты даже не понял, зачем он был нужен?

@COKPOWEHEU · 17.08.2021, 13:38

Сообщение от DrOffset

У вас тут смешаны понятия implementation-defined behavior, unspecified-behavior и undefined-behavior.

Так ведь они и в реальности не слишком далеки друг от друга.

Сообщение от DrOffset

По его определению этот как раз не UB, потому что в этом случае по идентификатору мы точно понимаем что было записано при отправке события

Приблизительно оно выглядит так:

C
1
2
3
4
5
6
7
8
9
10
11
struct Event{
  uint32_t type;
  uint8_t reserved[?];
};
struct Event_moude{
  uint32_t type;
  uint16_t x, y, wheel;
  uint8_t button[3];
  uint8_t reserved[?];
};
и т.д.

То есть обработчик событий ОС заполняет структуру Event_mouse, а юзерский код читает сначала Event, полагаясь на то, что поле type будет расположено в одном и том же месте. Налицо запись в одну версию union'а, а чтение из другой.

Сообщение от DrOffset

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

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

Сообщение от DrOffset

Не понятно почему аргументация к спецификации языка является "криками"

Спецификация языка не говорит, что программа, содержащая UB, некорректна или тем более не должна компилироваться. Учитывая особенность С/С++, обойтись вот совсем без UB вряд ли возможно. Либо код станет совершенно нечитаемым и неэффективным. Уж слишком много они позволяют разработчикам компилятора.
Ну а агрессивное навязывание своих фантазий, противоречащих реальному миру, и выглядит как бесполезные крики. Как полагались люди на безопасность переполнения знаковых чисел, так и будут. Как кастовали что угодно к чему угодно, так и будут. Как считали байт восьмибитным, так и будут считать. Не нравится - пусть идет в другие языки, где подобные вольности не дозволяются.

Сообщение от hoggy

а зачем ты его начал чуть упрощать,
если ты даже не понял, зачем он был нужен?

Ну так разверните свою мысль. Что именно иллюстрирует ваш код и как он относится к вопросу Verevkin'а о касте int -> float?

@DrOffset · 17.08.2021, 13:49

Сообщение от COKPOWEHEU

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

Не замещайте общее частным.

Сообщение от COKPOWEHEU

Спецификация языка не говорит, что программа, содержащая UB, некорректна

Не говорит, но и гарантий корректности тоже не дает. Это прямо и означает, что программа в неопределенном состоянии.

Сообщение от COKPOWEHEU

тем более не должна компилироваться.

Про "компилироваться" там выше было совсем в другом контексте сказано. Не в том смысле, что не компилируется из-за UB. Там не компилировалось из-за неявного каста между несовместимыми типами.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU

Налицо запись в одну версию union'а, а чтение из другой.

Для такого случая, когда есть layout-compatible, и С++ тоже разрешает это делать.
Речь же не об этих случаях.

@COKPOWEHEU · 17.08.2021, 14:49

Сообщение от DrOffset

Не замещайте общее частным.

Я замещаю теорию реальностью.

Сообщение от DrOffset

Не говорит, но и гарантий корректности тоже не дает. Это прямо и означает, что программа в неопределенном состоянии.

Нет. Это означает, что она может в каких-то случаях работать неправильно. Но в тех условиях, под которые писалась, работать будет как задумано.

Сообщение от DrOffset

Про "компилироваться" там выше было совсем в другом контексте сказано. Не в том смысле, что не компилируется из-за UB.

Не, TheCalligrapher постоянно говорит что мол "скомпилировалось по случайности", "компилятор не должен такого допускать" и другие высказывания в духе "если программа расходится со стандартом, она однозначно нерабочая, и в принципе не должна компилироваться".

Сообщение от DrOffset

Речь же не об этих случаях.

Так я несколько разных вариантов привел.

@DrOffset · 17.08.2021, 14:58

Сообщение от COKPOWEHEU

Так я несколько разных вариантов привел.

Ни один из них не подходит, потому что они все используются в Си. Выше было сказано:

Сообщение от TheCalligrapher

такое допустимо только в С

Часть их них при этом легальны и в С++. Такого однозначного определения по которому все ваши варианты UB

Сообщение от COKPOWEHEU

Но по определению TheCalligrapher, это все равно UB.

не было.

Сообщение от COKPOWEHEU

другие высказывания в духе "если программа расходится со стандартом, она однозначно нерабочая, и в принципе не должна компилироваться".

Наверняка если сейчас начнем разбирать конкретные примеры, то, как и здесь, окажется, что все не совсем так.

Новые блоги и статьи Все статьи Все блоги /
Как надо было делать правильно - вообще не слушать ИИ, его дело - текст. Hrethgir 15.07.2026 А вообще надо было делать не так, чтобы не исправлять ошибку https:/ / www. cyberforum. ru/ blogs/ 223907/ 10996. html , правильно было : удалил кнопку, а потом добавил её. Всё это стресс конечно. Почему?. . .	Знаете, от чего появляется стресс? kumehtar 15.07.2026 Стресс появляется оттого, что вы, зная как поступить правильно, делаете наоборот. Ларри Уингет	Нас бьют, а мы крепчаем? Какая чушь! kumehtar 15.07.2026 Вот это вот бытующее мнение, что человек меняется только под действием проблем, всегда считал вредоносным. Поверь, от проблем у людей появляются не изменения, а нервное расстройство и ПТСР. А. . .	сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .
сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .	сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .

@Catstail Супер-модератор 38210 / 21143 / 4313 Регистрация: 12.02.2012 Сообщений: 34,756 Записей в блоге: 14
	16.08.2021, 22:12
	TheCalligrapher, нет это не троллинг. Это вопрос к системе типов. Что стоило просто запретить подобные преобразования - и не было бы проблем. Если Вы мне объясните это (и я пойму), то буду благодарен... Когда меня убеждают - я соглашаюсь. А вот когда мне заявляют менторским тоном "Это так и никак иначе", а на вопрос "Почему?" отвечают "Потому", то я упираюсь. Мне кажется, это мое право. 2

@Catstail Супер-модератор 38210 / 21143 / 4313 Регистрация: 12.02.2012 Сообщений: 34,756 Записей в блоге: 14
	17.08.2021, 07:02
	TheCalligrapher, понял. Спасибо. 0