Russian Qt Forum

Есть такая ситуация, число лежит в массиве побайтно младшими вперед например 0x020e, т.е. как сделать так, чтобы записать число в quint16? пробовал ,чтобы явное преобразование захватило сразу два байта, но что то не выходит, прошу помощи.

buf[0]

да и buf[0] пробовал выдает не 2 а 14, что то тоже не то, там вроде указатель должен быть???

наверное что-то типа такого должно быть:

C++ (Qt)
quint16 n = *(reinterpret_cast<quint16 *>(buf));

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

qFromLittleEndian, qFromBigEndian.

будет работать до поры до времени, пока адрес buf выровнен. если не проследить за выравниванием, то словите ошибку во время выполнения, причем трудноуловимую. лучше не баловаться подобным приведением типа, а сделать что-то типа

quint16 n = buf[0] + (buf[1] >> 8);

Что за мифическое выравнивание? Давайте проверим

C++ (Qt)
#pragma pack(push, 1)
struct CTest {
 char ch;
 char buf[128];
};
#pragma pack(pop)
...
CTest test;
quint16 * dst = (quint16 *) &test.buf[0];
*dst = 5;
qDebug() << dst << *dst;
 

Неужели *dst не будет правильно читаться/писаться если стоит по нечетному адресу ?  :)

А не везде эти прагмы работают. Например последний случай на UC-8410 = http://www.moxa.com/product/UC-8410.htm (http://UC-8410 = http://www.moxa.com/product/UC-8410.htm), ARM процессор, эти прагмы не работают. Выравнивание 4.

я присал вы же мне привели код, в котором проследили за выравниванием. Во вторых ваш тестовый код не выявит ни чего.

вывод в любом случае будет 5

лучше так проверить

Давайте так (чуть изменил печать)

C++ (Qt)
#pragma pack(push, 1)
char buf[128] = {0};
#pragma pack(pop)
 
buf[1] = 0x34;
buf[2] = 0x12;
quint16 *dst = (quint16 *) &buf[1];
printf("dst = 0x%x\n", (int) *dst);
*dst = 0xABCD;
printf("dst = 0x%x\n", (int) *dst);
 

Вывод

С чего Вы это взяли ??? Пишется начиная с того адреса который дали. Просто если он не выровнен, процессор затратит больше времени ("штрафные такты" и все такое) - но никакой ошибки мы не словим

Вы ошибаетесь. Точнее пытаетесь судить обо всем по своим знаниям.
А человек выше даже указал процессор, который не умеет читать не выровненные данные.

А о чем вообще спор? ТС спросил как из байтового массива получить 2-хбайтное? Ему посоветовали
Видать ТС новичок и плохо разбирается в привидении типа.  Он этот код использует у себя.... и возможно его buf[0] выровнен к 4. Или у него процессор 8-ми битный. Он в своем коде ни когда не словит ошибку.  Я предостерёг, что пользуясь таким кодом нужно следить за выравниванием. В чем я не прав? Ни кто ему не сказал сделай так Нужно понимать, что на конкретной архитектуре выравнивание может быть 2 или 4. На некоторых архитектурах не работают прагмы. То, что вы проверили на конкретной архитектуре и заработало - это не значит что будет работать везде. На AVR без прагмы всё будет работать.
ТС использует такое приведение типа без прагмы, как посоветовали, код будет работать. ТС усвоит урок. Потом в другом месте сделает также (или использует этот код)... и обратится по невыровненным данным.... выстрелит себе в ногу. "Прозанимается любовью" с этой багой.... и соскочит на жаву. А потом возникают на форумах холивары, что с/с++ гавно.

Вы в своем коде проследили за выравниванием, т.е. вы прагмами изменили выравнивание к 1. Я говорю тоже самое - нужно учитывать выравнивание.

psя уже говорил, что такой код не дает проверки. если разыменование *dst происходит неправильно, то вы в неправильный адрес запишите 0xABCD, а потом проверяете прочитав также из неправильного адреса.

Цитированием не злоупотребляйте плз
Трогательная забота о ТС - но у него своя голова есть :) А захочет на жабу - тем лучше, слабаки не нужны. Еще до PowerPC я работал на Mac, тогда проц motorola не умел писать в нечет - но он выбрасывал исключение "address must be even". Если опять такой появится и возникнет необходимость его поддержки (Вашу ссылку открыть не могу, но гипотетически это возможно)- ну тогда много чего полетит, и много чего придется переписывать. А до этого не стоит шарахаться от мифических угроз, типа "а вот есть такой проц где.. и тогда, тогда... о ужас!!!"  :) Стандарт запрещает писать по невыровненному адресу? Насколько мне известно - нет. Ну и все, а там посмотрим. Заказ на работу с причудливым процом еще надо получить.

Вот куда более реальная проблема: на Вындоуз тип long всегда 4 байта. а вот на Mac он 8 в 64-bit но 4 в 32-bit. Связанные с этим ошибки совсем не редки. Следуя Вашей логике нужно немедленно истребить все long заменив на что-то типа SInt32. Но сделали ли Вы это?  :)

Если на конкретной архитектуре выравнивание 4, то с подобным приведением типа вы должны позаботиться о выравнивании. либо вы должны чтобы buf был кратен 4, либо вы должны указать прагмой нужное выравнивание. выравнивание 4 - это не мифический процессор. Вот  http://www.moxa.com/product/UC-8410.htm - вполне не мифическая микроЭВМ с немифическим Intel XScale IXP435 533 MHz processor.


Смешно както.... "Что за мифическое выравнивание? Давайте проверим" - и тут же приводите проверочный код, в котором вы позаботились о выравнивании. Если это выравнивание мифическое, зачем вы прагмой изменили выравнивание к 1? Ваш проверочный код выровнен к 1. И данные выровнены к 1. Можно спокойно обращаться к адресам кратным 1. Вы проверьте без выравнивания.

От каких мифических угроз?  На любом процессоре и любой архитектуре, если делаешь привидение типа
проследи, чтобы буф был выровнен. если по дефолту выравнивание 4 - смотри чтоб буф был выровнен к 4. Если ваш буф по нечетному адресу, то измени выравнивание к 1 (хотя не везде это сработает). Так или иначе, но программист обязан следить за выравниванием, при подобном приведении типа. В чем я не прав?

С ваших слов, выравнивание это миф и о нем заботиться не нужно. И в качестве доказательства приводите пример с выровненными данными. В чем смысл?

Возможно Вы имели ввиду нечто типа

C++ (Qt)
struct CTest {
  char ch;
  quint16 val;
}; 
CTest test;
...
 
quint16 n = *(reinterpret_cast<quint16 *> (&test.ch + 1);
 

Да, это неверно, n будет совсем не test.val, до которого еще 1 байт. Да, если сделаем #pragma pack 1 для CTest - тогда будет верно. С этим никто не спорит, но это совсем не значит что reinterpret_cast что-то "не так приводит" или читается/пишется куда-то "налево". reinterpret_cast четко работает с тем адресом что дали. Напр если это &test.val - то он и будет читаться/писаться, какое бы выравнивание ни стояло.

Я открыл ссылку, поискал "align" - не нашел. Пожалуйста "ткните носиком".  

Есть куча армов, которые не могут обращаться по не выравненным адресам. Вместо доступа будет генерироваться прерывание.
Для правильного доступа, нужно что бы оперант в памяти был выравнен на свою длину, т.е. хотим читать 16 битное число из памяти, оно должно быть выравненно на 2 байта, если 32 битное - то на 4. Нет получи прерывание. Конечно можно самому эмулировать чтение через побайтовое, но это лишние такты.
Зная это, компиляторы генерируют правильный код, пока программист не дотягивается до ручного привидения типов, там компилятор становится бессильным и программист должен все контроллировать сам.

Да, действительно, juvf прав, есть такие звери. Вот нашел популярное описание
http://www.aleph1.co.uk/chapter-10-arm-structured-alignment-faq (http://www.aleph1.co.uk/chapter-10-arm-structured-alignment-faq)
Причем да, могут и "втихаря" неверно читать/писать. Признаю - был неправ  :)

проверил на дэсктопе код
в результате n = 770, т.е. т = 0x0302, то что доктор прописал. Процессор i7, винда7, 64х. без всяких прагм заработало.

Запустил этот код на девайсе с процессором AT91SAM7S256 (ARM архитектура) - на строке с reinterpret_cast процессор завис. печалька.

Ну да ладно.... SAM7 наверно мифический.... собрал такой код в UC-8410 (процессор Intel XScale IXP435, ARM-архитектура)

Запускаю.... смотрю выхлоп
от куда 258? должно быть 0х0302, что есть 770.  ??? .... а 258 - это есть 0х0201. Как так?! Я же указывал адрес ch + 1, и   reinterpret_cast работает строго с указанным адресом...... так так так... пробуем исправить положение прагмой..... а не вышло.... выхлоп такой же... 258 вместо 770.
 

Да да да.... Самое печальное, что некоторые именно втихаря. Ладно сам7 сразу завис. А так втихоря уйдет в сторону.... замучаешься искать.  :)

У Вас там что, тазик с процессорами ? :)