Интерпретация переменной типа 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

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

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

Новые блоги и статьи Все статьи Все блоги /
Термопринтер QR701 Argus19 03.08.2026 Термопринтер QR701 Купил два термопринтера QR701. На сэлф-тесте написано: Language: PC936 (GB18030). Что означает, что принтеры могут печатать только латиницу и китайские иероглифы. Так же. . .	Создание формы заимствованного документа Maks 03.08.2026 Задача: Необходимо создать собственную форму заимствованного документа. На форме должен быть реквизит "Покупатель", а также табличная часть со следующими реквизитами: - Расчетный счет покупателя. . .	Задача предоставления скидок покупателям Maks 03.08.2026 Задача: В документе "Продажи" необходимо реализовать функционал предоставления скидок покупателям. Скидка должна автоматически рассчитываться и подставляться в соответствующее поле при выборе. . .	Почему SEO не начинается с ключевых слов: что проверить до написания текстов Neotwalker 01.08.2026 Когда владельцу сайта предлагают заняться SEO, первым шагом часто становится сбор запросов и написание текстов. Логика кажется понятной: 1. Находим ключевые слова. 2. Добавляем их на. . .
Знание — сила: Доктрина интенциональности знаний, углубление в формулу Hrethgir 01.08.2026 https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11957&stc=1&d=1785567302 Знаменитый афоризм Фрэнсиса Бэкона «Знание — сила» (Scientia potentia est) в массовой культуре принято понимать. . .	SUNO Ai - Река Без Дна zorxor 31.07.2026 Автор стихотворения - астрофизик Марина Катыс Ссылка на сгенерированную музыкальную композицию: https:/ / suno. com/ song/ 6f6e5464-b290-4650-be6c-44c85f8d8013 Я говорю, что Время- как вода течет. . .	Из невошедшего на форум (диалог с ИИ-гугла) zorxor 29.07.2026 А вот, что интересно, сказал мне ИИ-гугла: Этот текст — эмоциональный пост пользователя под ником zorxor на интернет-форуме (вероятно, посвященном мистике, непознанному или альтернативной науке). . . .	Был праздник вчера, а я и не знал. kumehtar 28.07.2026 27. 07. 2026г. Intel Core 2 Duo исполнилось 20 лет Салют, шампанское, овации! :drink:

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

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