LINUX.ORG.RU
Форум — Development  

преобразование знаковых в беззнаковые

 ,


0

1

Стандарт С++ 98/2003 3.9.1.3 

each signed integer type has the same object representation
as its corresponding unsigned integer type.

Я правильно понимаю, что это означает, что можно сделать так 

int a = -5;
unsigned int a_new = 0;
usigned char buf[sizeof(int)];
memcpy(&buf,&a,sizeof(int));
memcpy(&a_new, &buf, sizeof(int));
a=0;
memset(buf,0,sizeof(int)];
memcpy(&buf,&a_new,sizeof(int));
memcpy(&a,&buf,sizeof(int));
И мы восстановим изначальное значение? Ну что стандарт это грантирует? И вопрос два. Правильно ли я понимаю, что следующий код по стандарту не гарантированно работает? 
int a = -5;
unsigned int a_new = (unsigned int) a;
a=0;
a = (int) a_new;
Вопрос вот к чему. Сетевые функции htonl и прочие принимают на вход беззнаковые типы. А если я хочу передать знаковый? При передачи его в такую функцию будет преобразование к знаковому. А можно ли делать при получение данных обратный каст? Есть ли в стандарте гарантия, что при обратном касте на другой платформе мы восстановим число?

★★★★★
← Поддержка компиляторами
ConditionVariable.wait: 1.8 vs 1.9 →

Ответ на: комментарий от mv

И? Прочитал, потому и спрашиваю. В стандарте идет разделение понятий object representation и value representation

The object representation of an object of type T is the sequence of N unsigned char objects taken up by
the object of type T, where N equals sizeof(T). The value representation of an object is the set of bits
that hold the value of type T. For POD types, the value representation is a set of bits in the object representation
that determines a value, which is one discrete element of an implementation-defined set of values.

В приведенном выше куске говорится лишь о object representation

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

Хотя исходя из

For POD types, the value representation is a set of bits in the object representation

that determines a value, which is one discrete element of an implementation-defined set of values.

Можно предположить, что это справедливо и для базовых типов, тогда для них object representation и value representation совпадают. И второй способ вполне гарантировано работает. Я прав?

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

ТОчнее базовые и есть тоже POD, тогда получается одно и тоже. И правда. Просто запутался. Подумал, что в разделе про целые числа не зря указали именно object representation

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

Первое будет работать, второе - нет. Используй дополнительный код, если очень так уж надо, или макросы преобразования endianness'а, не привязанные к сети.

slapin ★★★★★
()

вангую, что оба варианта будут работать

Сетевые функции htonl и прочие принимают на вход беззнаковые типы. А если я хочу передать знаковый?

скастуется в беззнаковый. Вообще битовое представление числа при этом не меняется, меняется наше (компилятора) отношение к этому числу - считаем его либо знаковым, либо беззнаковым

Harald ★★★★★
()
Ответ на: комментарий от Harald

Вообще битовое представление числа при этом не меняется, меняется наше (компилятора) отношение к этому числу - считаем его либо знаковым, либо беззнаковым

Так то оно может и так, но кто гарантирует, что это требование стандарта, а не особенность реализации.

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от slapin

Ну да, пожалуй проще memcpy скопировать возможно. Макросы я так понимаю свои писать? Ну это черевато проблемами с переносимостью, ну или как минимум лишней работой и лишними работами. Вариант с memcpy вроде универсальный будет.

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

нет, есть #include <endian.h>, но хз насколько он стандартен.

slapin ★★★★★
()
Ответ на: комментарий от Dudraug

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

Проблем с переносимостью нет. Везде, куда тебе удастся перенести, отрицательные числа кодируются в 2's-complement прямо в железе.

Вариант с memcpy вроде универсальный будет.

Это бред, если честно.

mv ★★★★★
()
Ответ на: комментарий от mv

прямо в железе.

Проблем с переносимостью нет.

/0

Я как раз и говрю о том, что теоретически возможно встретить железку где это не так. Или это невозможно в принципе?

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

Это как встретить троичную ЭВМ. Возможно, но лишь в теории.

PolarFox ★★★★★
()
Ответ на: комментарий от Dudraug

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

ckotinko ☆☆☆
()
Ответ на: комментарий от ckotinko

Ну так я понимаю. Вопрос был по сути чисто теоретическим, плюс на «чтобы быть готовым если встречу».

Dudraug ★★★★★
() автор топика
Ответ на: комментарий от Dudraug

Я как раз и говрю о том, что теоретически возможно встретить железку где это не так. Или это невозможно в принципе?

Теоретически встретить возможно (слава FPGA!), но на этой железке C++ компилятора, соответствующему 98/2003 3.9.1.3, не будет.

mv ★★★★★
()
Ответ на: комментарий от Dudraug

тогда уж лучше С++ ABI выучить. как физически в gcc делается класс с виртуальными перегруженными функциями, заглушки где стоят и vtable устроен. там все вроде просто но спрашивают. или можно ли вызвать метод от null? да если не виртуальный.

а на такую муру честно отвечать «я работал только с земными двоичными ЭВМ. как это сделано у марсиан понятия не иму»

ckotinko ☆☆☆
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Поддержка компиляторами
Development
ConditionVariable.wait: 1.8 vs 1.9 →