Перевести биты int в unsigned int

Доброго времени суток, как можно получить из int -> unsigned int, т.е. где все биты в таком же порядке, по идее тогда будет без минуса.

Пример:
int - -2147483647
unsigned int - 0

int 0
unsigned int - 2147483647

0

Я по-прежнему не понимаю, в чом проблема. Объясните мне, дебилу, чо не так-то?

0

k0vpack, расскажи конкретно задачу (одними словами, без использования C++), что ты пытаешься сделать? Возможно, ты неправильный путь выбрал. Я бы даже сказал - это очевидно

0

Сообщение от rat0r Насколько мне известно, UB. memcpy-то между двумя объектами одного trivially copyable типа "разрешён" только ненормативной сноской, а между разными типами это вообще ХЗ что значит.

Это очень интересный вопрос. Казалось бы задача весь тривиальная или нет? Если выйти в интернет с таким вопросом, о type punning'е в С++, то вариант с memcpy самый популярный что ли и там утверждают, что это ОК. Но так ли это?
Что говорит стандарт:

Сообщение от N4659 6.9/2 For any object of trivially copyable type T, whether or not the object holds a valid value of type T, the underlying bytes making up the object can be copied into an array of char, unsigned char, or std::byte. [...]

Сообщение от N4659 6.9/3 For any trivially copyable type T, if two pointers to T point to distinct T objects obj1 and obj2, where neither obj1 nor obj2 is a base-class subobject, if the underlying bytes making up obj1 are copied into obj2, obj2 shall subsequently hold the same value as obj1.

Я конечно не знаток, но здесь вроде как говорится то, что если мы хотим скопировать два объекта (underlying bytes), то мы это можем сделать только тогда, когда они имеют the same trivially copyable type T. Тогда, тот же популярный type punning между int и float даже через memcpy - UB. И в С++20 тоже, ведь в новом стандарте эти строчки не изменились, но появился bit_cast, который вроде вот все, наше спасение и разрешает кастить даже между разными типами:

Сообщение от N4830 26.5.3/1 Returns: An object of type To. Each bit of the value representation of the result is equal to the corresponding bit in the object representation of From.

Ну, допустим там происходит какая-то магия )

Но, вернемся к С++17, что мы имеем на данный момент? Почему каст при помощи memcpy не UB? Ну, как минимум можно сказать, потому, что memcpy интерпретирует оба объекта как unsigned char*, при таком условии все получается как по маслу, теперь это не каст между разными типами и все ОК, до того времени пока мои объекты которые я хочу скастить не перекрываются, иначе опять UB. С другой стороны есть memmove, который работает, как и memcpy и еще сверху говорит, что objects may overlap и это не UB.
Хм, а значит ли это то, что можно написать так:
?
В общем компилятор генерит одинаковый output, что с bit_cast, что просто pun'ить через неактивное поле.
https://godbolt.org/z/LBKUEO
https://godbolt.org/z/AxKkZh


Получается в С++17 мы безопасности пока наши объекты: TriviallyCopyable, одинакового размера и пока memcpy гарантирует представление объектов как unsigned char*?
Наверное, да
Еще стоило бы упомянуть о выравнивании, у нас нету гарантии, что unsigned char* будет выровнен, но это другая история

0

Сообщение от Azazel-San то мы это можем сделать только тогда, когда они имеют the same trivially copyable type T.

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

Сообщение от Azazel-San Хм, а значит ли это то, что можно написать так:

Нет, так нельзя. Strict aliasing запрещает такое делать. Но при этом стандарт разрешает взять некоторый объект, представить его в виде массива байт и записать что-либо в этот массив. Это будет не UB, пока у объекта остается корректное значение.

0

Сообщение от nonedark2008 Про объекты разных типов там ничего не сказано.

Ну, именно. Про объекты разных типов ничего не сказано.

Сообщение от nonedark2008 Strict aliasing запрещает такое делать.

Можно подробнее, такое это какое? Что именно?
Из-за strict aliasing мы не можем pun'ить через не активное поле union'a - это понятно, тут он запрещает.
Я же так не делаю, плюс memmove дает гарантию, что объекты могут перекрываться:

The objects may overlap: copying takes place as if the characters were copied to a temporary character array and then the characters were copied from the array to dest.

И это не будет UB.

0

Сообщение от Azazel-San union { * * int * i; * * float f; }

В C++, в отличие от C, type punning через union является UB.

0

Сообщение от nonedark2008 В C++, в отличие от C, type punning через union является UB

В Си тоже UB

Добавлено через 54 секунды
Если я правильно понял, какой смысл вкладывается в "type punning"

0

Сообщение от Evg В Си тоже UB

Сообщение от Evg Если я правильно понял, какой смысл вкладывается в "type punning"

Я имел ввиду что-то такое:
Где-то читал, что в Си это не UB.

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

Сообщение от Azazel-San Я же так не делаю, плюс memmove дает гарантию, что объекты могут перекрываться:

Вот кстати точно не знаю. Strict aliasing зарпещает рассматривать одну и ту же область памяти как объекты разных типов (с некоторыми исключениями). В memmove скорее всего подразумевается, что перекрываться могут только области памяти, соотвествующие объектам одного и того же типа.

0

Сообщение от nonedark2008 В C++, в отличие от C, type punning через union является UB.

Aaa?

Сообщение от N4659 6.10/8 If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined: [...] an aggregate or union type that includes one of the aforementioned types among its elements or nonstatic data members (including, recursively, an element or non-static data member of a subaggregate or contained union), [...]

Union не нарушает strict aliasing.

Сообщение от nonedark2008 type punning через union

Еще раз я же делаю это не через НЕ активное поле.

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

Сообщение от nonedark2008 В memmove скорее всего подразумевается, что перекрываться могут только области памяти, соотвествующие объектам одного и того же типа.

Вот это уже интересно, но так нигде не сказано.

0

Сообщение от Azazel-San Еще раз я же делаю это не через НЕ активное поле

В твоём примере из поста #23 не совсем понятно, зачем использовался union. Проще было бы использовать отдельную переменную типа int и отдельную типа float, дабы не загромождать вашу обсуждаемую проблему лишними сущностями. Это в свою очередь привело к неправильному пониманию в посте #26, а может быть и излишней каше в собственной голове. Честно говоря, мне лень вникать в весь ваш диалог, но, если я правильно понял, то в посте #23 ты попросту сравнивал два разных подхода, которые более корректно было бы записать так:

Да, оба варианта дадут одинаковый результат. Но по факту второй вариант является некорректным, т.к. нарушает strict aliasing, а первый вариант в случае использования memcpy является законным, а в случае memmove - точно сказать не могу, но скорее всего тоже законен

0

Сообщение от Evg ты попросту сравнивал два разных подхода

Ну, да. Я хотел узнать можно ли делать тоже самое с memmove, что делают и с memcpy? С поправкой на возможности memmove.
Просто union это пример этих самых перекрывающихся объектов.
Вообще исходя из описания memmove, я хотел сделать так:

Сообщение от Evg Но по факту второй вариант является некорректным, т.к. нарушает strict aliasing

Верно, но я же так не делаю. Я не читаю из поля .f пока активен .i

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

Сообщение от nonedark2008 Где-то читал, что в Си это не UB.

Кстати в Си таки это вроде не UB.

Сообщение от N2434 6.2.6/6 When a value is stored in an object of structure or union type, including in a member object, the bytes of the object representation that correspond to any padding bytes take unspecified values. The value of a structure or union object is never a trap representation, even though the value of a member of the structure or union object may be a trap representation.

Да и в Си нету активных или не активных полей. Или я не увидел?

0

Сообщение от nonedark2008 Где-то читал, что в Си это не UB

Сообщение от Azazel-San Кстати в Си таки это вроде не UB

По ходу вы правы, а я ошибся

Приведение указателя базового типа
(правда русскоязычный перевод не совсем корректен)

Там выдержка НЕ из стандарта, но, вероятно, так оно и есть. Т.е. начиная с C99, судя по всему, узаконили запись в одно поле union'а и чтение из другого поля

Ну и вот здесь немного разжёвано: https://stackoverflow.com/ques... esentation

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

Сообщение от Azazel-San Вообще исходя из описания memmove, я хотел сделать так:

Для Си именно так было бы естественным. Но для Си++ с концепцией шаблонов так красиво не получается, всегда вылезает промежуточное значение. При вызове memmove напрямую действительно можно было бы вести речь о пересекающихся данных, но в твоей реализации bit_cast об этом говорить не приходится, ибо работа идёт через value

0

Сообщение от Evg но в твоей реализации bit_cast об этом говорить не приходится, ибо работа идёт через value

Там еще стоит учитывать copy elision. Компилятор имеет право не создавать временную переменную, а напрямую работать с возвращаемым значением.

Сообщение от Azazel-San C++ 1 std::memmove(&type_pun.f, &type_pun.i, sizeof(type_pun.f));

Единовременно активен либо type_pun.f либо type_pun.i. Разве запись по адресу type_pun.f не будет эквивалентна записи в еще не инициализированный (или даже еще не созданный с точки зрения стандарта) объект?

0

Такое тоже UB? (сейчас конкретно для типов с одинаковыми объемами памяти)

Я такое понимаю как насильственный вывод sizeof(unsigned int) байт по pv в представлении unsigned int. //или я не так понимаю?

Это я так понял что автору нужно, хотя не уверен что правильно понял.

0

Сообщение от Folian Такое тоже UB?

Нет, тут все ок, с этим мы уже разобрались. Но если вместо unsigned int вставить, скажем, float (одного размера с int), то уже будет UB. Это поведение прописано в графе [basic.lval] стандарта.

1

Сообщение от Azazel-San Почему каст при помощи memcpy не UB? Ну, как минимум можно сказать, потому, что memcpy интерпретирует оба объекта как unsigned char*

Что значит "интерпретирует как unsigned char*"?

Сообщение от nonedark2008 Но при этом стандарт разрешает взять некоторый объект, представить его в виде массива байт и записать что-либо в этот массив.

Ого. Это где такое разрешает?

Сообщение от nonedark2008 Где-то читал, что в Си это не UB.

Стоит читать не где-то, а в стандарте C.
А там на этот счёт только одна мутная сноска.

Сообщение от Azazel-San If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined: [...] an aggregate or union type that includes one of the aforementioned types among its elements or nonstatic data members (including, recursively, an element or non-static data member of a subaggregate or contained union), [...] Union не нарушает strict aliasing.

В C++ не существует access через glvalue of union type. Так что этот подпункт про union выпилили.

Сообщение от nonedark2008 Нет, тут все ок, с этим мы уже разобрались.

Ну и какое же поведение у кода
(указатель на void ничего не меняет, так что я подсократил код)???

1

Сообщение от rat0r Ого. Это где такое разрешает?

Потому что к объекту разрешено получать доступ через char, unsigned char и std::byte, как сказано в [basic.lval].

Сообщение от rat0r Ну и какое же поведение у кода

Определенное.

rat0r, у тебя есть какие-то другие сведения на этот счет?

0

Сообщение от Evg Там выдержка НЕ из стандарта, но, вероятно, так оно и есть.

Да потому что, со стороны архитектуры и компьютера такое преобразование вполне понятное.
Если посмотреть на ядро Линукса, там везде такое и это ОК (речь о Си).

Сообщение от Evg Для Си именно так было бы естественным.

И для меня странно почему это не так для С++.

Сообщение от nonedark2008 Компилятор имеет право не создавать временную переменную, а напрямую работать с возвращаемым значением.

Она там по любому создается. Причем там copy elision?

Сообщение от rat0r Что значит "интерпретирует как unsigned char*"?

Это:

Copies count characters from the object pointed to by src to the object pointed to by dest. Both objects are reinterpreted as arrays of unsigned char.

Сообщение от rat0r Так что этот подпункт про union выпилили.

И что это значит?

Сообщение от rat0r Ну и какое же поведение у кода

Не понятное?..

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

Сообщение от nonedark2008 Потому что к объекту разрешено получать доступ через char, unsigned char и std::byte

После каста к ним?
Где это? Можно цитату?

0

Сообщение от Azazel-San Да потому что, со стороны архитектуры и компьютера такое преобразование вполне понятное

Это-то да. Но strict aliasing rules - это то, что нужно компилятору для эффективной работы. По факту type punning через union работает на любом более-менее адекватном компиляторе. Просто потому, что по факту это используется много где, несмотря на то, что с точки зрения стандарта является не законным, а потому в компиляторах это поддержано. Благо такие случаи не вызывают никаких проблем ни с реализацией, ни с производительностью. Это один из тех редких случаев, когда здравый оказался выше стандарта

1

Сообщение от nonedark2008 Потому что к объекту разрешено получать доступ через char, unsigned char и std::byte, как сказано в [basic.lval].

[basic.lval] только запрещает доступ кроме как через определённые типы, но не говорит что будет при доступе через разрешённые. Отсутствие запрета ≠ определение поведения.

Сообщение от nonedark2008 Определенное.

Ну вот расскажи подробно (по шагам) и с ссылками на стандарт как вычисляется выражение *reinterpret_cast<unsigned int*>(&a); что получится в результате.

Сообщение от Azazel-San Both objects are reinterpreted as arrays of unsigned char.

Ну с точки зрения стандарта плюсов это не очень понятно что значит.

Сообщение от Azazel-San И что это значит?

Да ничего не значит, он никогда не использовался.

0