Как массив char[4] перевести в unsigned int?

Есть массив из 4х char символов (4-е байта), нужно его перевести в unsigned int.
Я сделал втупую:
Можно ли это как-то упростить?.. а то уж слишком некрасиво, долго и программу засоряет...

Я мыслю так, т.к. обе переменные (и 4-е char'a, и int) 4-х байтовые, то появилось предположение, что можно, как-нибудь, например, обратиться к char-массиву, сразу записав его в переменную int не преобразовывая?..

0

Сообщение от bugaboo а практическая разница какая-то есть?

есть. https://habrahabr.ru/post/106294/

C-style cast по сути самое медленное преобразование, так как в этом случае последовательно перебираются следующие вызовы: const_cast static_cast static_cast + const_cast reinterpret_cast reinterpret_cast + const_cast

0

Сообщение от TRam_ C-style cast по сути самое медленное преобразование, так как в этом случае последовательно перебираются следующие вызовы

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

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

0

https://habrahabr.ru/post/106294/

Ой-ой. Яркий пример того, как автор сел писать статью, еще не до конца разобравшись в вопросе. Порочная практика, по моему мнению.

Сообщение от bugaboo а практическая разница какая-то есть?

Практическая разница в том, что С-style cast плохо видно в коде (его трудно искать автоматическими средствами), а его универсальность плохо способствует отражению намерений программиста: из кода не понятно, что мы в итоге делаем за преобразование; и такое преобразование "все-в-одном" может стать причиной сокрытия ошибки. Например, мы можем с легкой руки случайно снять константность с объекта и получить UB на его последующей модификации. И компилятор нам тут ничем не поможет.

Ну и есть еще несколько маленьких нюансов (надеюсь они никогда никому не понадобятся).
C-style cast позволяет сделать корректное static_cast преобразование в пределах иерархии классов с закрытым или защищенным (protected/private) наследованием в точке, где член иерархии недоступен (inaccessible), чего обычный static_cast сделать не позволит (т.к. он смотрит на access rights - и это хорошо, чем более строгий контроль, тем проще сохранить корректность программы).
5.4/4

The same semantic restrictions and behaviors apply, with the exception that in performing a static_cast in the following situations the conversion is valid even if the base class is inaccessible.

Кроме того, имеет место ситуация с поведением в случае каста неполных типов. Если оба или один из типов (тип к которому приводят и приводимый тип) являются классовыми неполными типами, то не определено какой из кастов в итоге будет применен: static_cast или reinterpret_cast, даже если типы связаны отношением наследования.
5.4/5

The destination type of a cast using the cast notation can be “pointer to incomplete class type”. If both the operand and destination types are class types and one or both are incomplete, it is unspecified whether the static_cast or the reinterpret_cast interpretation is used, even if there is an inheritance relationship between the two classes.

7

Сообщение от DrOffset Кроме того, имеет место ситуация с поведением в случае каста неполных типов. Если оба или один из типов (тип к которому приводят и приводимый тип) являются классовыми неполными типами, то не определено какой из кастов в итоге будет применен: static_cast или reinterpret_cast, даже если типы связаны отношением наследования.

не понятно.
reinterpret_cast можно применять только указателям или ссылкам жеж.
которые всегда являются полными типами.

static_cast в принципе не получится применить к неполному типу.

0

Сообщение от hoggy не понятно.

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

Добавлено через 1 минуту
Но в цитате это есть:

The destination type of a cast using the cast notation can be “pointer to incomplete class type”

1

Сообщение от bugaboo Evg, тогда, наверно, такой вариант будет универсальным? C++ 1 2 3 4 5 6         unsigned char buf[4];         unsigned int x = 0;         for (int i = 0; i < 4; i++)             buf[i] = ifs.get();         for (int i = 0; i < 4; i++)             x += buf[3 - i] << (i << 3); байты считываются заведомо как положительные числа в определенном порядке(файл заведомо big-endian, открыт как бинарный), а х вычисляется как сумма, то есть его представление в памяти не важно. У меня работает ))

Да что ты привязался к положительным и отрицательным числам. Они практически никакой роли не играют. Endian влияет на ПОРЯДОК, в котором надо извлекать байты из потока (или записывать в результирующую переменную). Универсальность кроме обеспечения правильного порядка больше ни от чего не зависит

Варианты из постов #16 и #17 точно так же никакого отношения к универсально работающему коду не имеют. Поскольку всегда читают и пишут в одном и том же порядке, а значит будут работать только на каком-то конкретном endian'е

0

Evg, то есть, на что конкретно будет влиять endian? на операции побитового сдвига влево, или на int, вычисляемый в виде суммы? Слово "отрицательные" я беру в кавычки, чтобы не писать "байты, у которых первый бит установлен в 1"

0

Сообщение от bugaboo на что конкретно будет влиять endian?

На порядок байт в числе.
https://ru.wikipedia.org/wiki/... 0%BE%D0%B2

0

Сообщение от Croessmah На порядок байт в числе.

А какое он для меня имеет значение то? Я же это число вычисляю как сумму, а не из байтов скрещиваю... простите, это, видимо, выше моего понимания...

Добавлено через 9 минут
сейчас у меня примерно вот такой код
что тут может не срастись?
или на big endian 2+2 # 4?

0

Я же это число вычисляю как сумму, а не из байтов скрещиваю...

Но эту сумму ты ж где-то будешь использовать? И массив с байтами у тебя тоже не "абстрактно откуда взялся", а вроде как из MIDI-файла.

Если речь об 32-битном беззнаковом числе, то при ошибке пересчёта endian'ов 2+2 = 67108864 . Потому что 2ка распознается как 33554432 .

0

Сообщение от bugaboo А какое он для меня имеет значение то? Я же это число вычисляю как сумму, а не из байтов скрещиваю

Что-то у меня (а может и не только) было какое-то помутнение разума. Просто тема endian'ов уже для форума настолько избитая, что в голове всё перемешалось и я немного позабыл про твою исходную постановку задачи

Действительно, вариант из поста #17 почти правильный, только нужно результат ifs.get() преобразовать к типу unsigned char (см. пост #10, просто в нём замени or на plus). Т.е. твой вариант НЕ будет зависеть от endian'а и всегда будет работать правильно. Но твой изначальный вариант вопрос о том, как бы это сделать попроще (т.е. тупо скопировав 4 байта без свистоплясок) он не решается из-за того, что есть разные endian'ы. Точнее, решается, но только с учётом enidan'а, что делает решение более громоздким, чем твоё

Прошу прощения, что внёс смуту

Добавлено через 2 минуты
TRam_, если в файле записано 0x11223344, то он прочитает это как 0x11<<24 + 0x22<<16 + 0x33<<8 + 0x44. Т.е. в host-представлении получится число, которое в big-endian лежит в памяти как 0x11223344. Т.е. то, что изначально требовалось

0

2 * 2^(8*3)

0

Т.е. в файле записано ПРЕДСТАВЛЕНИЕ, а в результате вычислений получается ЗНАЧЕНИЕ, соответствующее big-endian представлению

Добавлено через 54 секунды

Сообщение от TRam_ 2 * 2^(8*3)

Что-то тут ты явно намудрил

0

Evg, наверно, путаница от того, что я не автор темы, а просто озаботился тем же вопросом и тему развил. Под словом "попроще" я имел в виду покороче, поизящнее код. И вроде бы, этот код родился.
Спасибо всем большое!
TRam_, эту сумму я запишу куда то в класс, буду преобразовывать и на выходе у меня будет совсем другое MIDI. Так что порядок байт не важен. Возможно, возникнут проблемы подобного рода на выходе, но в стандарте SMF, к счастью, стабильный big-endian

0

Evg, это сдвиг на 3 байта влево. В случае если у нас ошибочное определение endian, то младший байт становится старшим, т.е. смещается на 3 байта влево. Но написал да, в неочевидном виде.

Добавлено через 2 минуты
bugaboo, вот я и говорю, что если портируешь свой код на машину с big endian'овым процессором, то обрабатываться будет неправильно. Если там у тебя просто копипаста этого значения, то к чему его хранить в int, когда можно в char[4] ?

0

TRam_, не могу дать крутую ссылку, но вот какая то статья
http://learnc.info/c/bitwise_operators.html
там написано, что для операций сдвига endian не имеет значения

0

bugaboo, но имеет значение для тех чисел, которые у тебя константы и/или локальные переменные, которые участвуют в вычислениях (например складываются с таким преобразованным числом, или производятся побитовые операции с ним и теми константами/переменными).

0

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

0

Сообщение от bugaboo Evg, наверно, путаница от того, что я не автор темы

Тьфу ты, точно. Короче, ты свой вопрос решил?

Сообщение от TRam_ Evg, это сдвиг на 3 байта влево. В случае если у нас ошибочное определение endian, то младший байт становится старшим

По-моему ты путаешь представление и значение. Операции сдвига выполняются над значением. Задача стоит в том, чтобы прочитать (вычислить) именно значение. У него делается это правильно

0

hoggy, то, что ответ с UB признан одним из лучших, по-моему недвусмысленно характеризует обитателей сего форума. Не так ли?

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

Сообщение от TRam_ есть. https://habrahabr.ru/post/106294/ C-style cast по сути самое медленное преобразование, так как в этом случае последовательно перебираются следующие вызовы: const_cast static_cast static_cast + const_cast reinterpret_cast reinterpret_cast + const_cast

Ха-ха-ха-ха! Писатель сей чуши думает, что что-то последовательно перебирается в рантайме?

0