Пишу уже 2й раз это сообщение , поэтому кратко( первый раз форум что-то сглючил) ((
Пишу под WM , код на С++ , MFC
BYTE* pbUnpackedData = NULL;
DWORD dwUncomprSize = 100;
pbUnpackedData = new BYTE[dwUncomprSize];
DWORD index = 1; //Skip data type
DWORD size = *((DWORD*)&pbUnpackedData[index]);// на этой строке дебаггер прекращает выполнение , выводит в output информацию , вроде регистры и все
При упрощении до такого
DWORD index = 1; //Skip data type
DWORD* pdwData = (DWORD*)&pbUnpackedData[index];
DWORD size = *pdwData;// Аналогично
если вместо этого написать
memcpy( &size, pdwData, 4);
то все работает, но как-то неправильно это .. хочется понять в чем проблема
ЗЫЖ Проект чистый , только созданный визардом VS2005, WM5( эмулятор и девайс одинаково)
Здравствуйте, Loki13, Вы писали:
L>Странно, что код брал из PC версии программы и там он был вполне рабочий.. это каки-то особенности WM или процессора?
Особенности процессора ARM.
--
Я думал, ты огромный страшный Бажище,
А ты недоучка, крохотный Бажик...
Здравствуйте, Loki13, Вы писали:
L>DWORD size = *((DWORD*)&pbUnpackedData[index]);// на этой строке дебаггер прекращает выполнение , выводит в output информацию , вроде регистры и все
Арм требует для двухбайтовых данных выравнивания по 2 байта, для 4 байтовых — по 4.
Здравствуйте, Alexander Shargin, Вы писали:
AS>Здравствуйте, Loki13.
AS>Похоже на data misalignment error. Попробуй привести &pbUnpackedData[index] к невыровненному указателю:
AS>
H>>Очень мерзкий код,
AS>Чем именно?
1) Непереносимый
2) Неэффективный
H>>Лучше аллочить new DWORD[ByteSize/sizeof(DWORD)] и потом если очень надо, то приводить к BYTE*
AS>И как это поможет обратиться к байтам со второго по пятый как к единому DWORDу?
Если надо обойти весь массив, то надобности в unaligned access не возникает. Если возникает, значит программер плохо понимает что такое портируемость и эффективность.
Никогда не пробовали код отлаженный на I386 собрать на PowerPC? Вот где открывается кем написана программа, грамотным инженером или народным умельцем-эникейщиком.
Здравствуйте, Handie, Вы писали:
AS>>Чем именно? H>1) Непереносимый H>2) Неэффективный
[skip]
H>Если надо обойти весь массив, то надобности в unaligned access не возникает. Если возникает, значит программер плохо понимает что такое портируемость и эффективность.
H>Никогда не пробовали код отлаженный на I386 собрать на PowerPC? Вот где открывается кем написана программа, грамотным инженером или народным умельцем-эникейщиком.
Давайте обойдёмся без громких слов и ярлыков, и будем оставаться в рамках сугубо технической дискуссии. Понятно, что в обычной программе "невыровненный" доступ к данным обычно не требуется. Понятно также, что в некоторых случаях он нужен — например, при обработке файлов или пакетов из сети, в которых данные записаны без выравнивания.
Когда возникает необходимость работать с такими данными, доступ к ним будет заведомо менее эффективным. Это особенность задачи, а не реализации, поэтому данный аргумент мимо кассы. Что касается переносимости, далеко не всем она нужна. Например, во многих проектах достаточно переносимости в пределах микрософтовских платформ. И здесь оптимальным является использование поддержки компилятора:
— Директива __unaligned.
— Директива #pragma pack, позволяющая описать структуру данных, с которыми мы работаем, с учётом их выравнивания (или его отсутствия).
Полученный код будет гораздо понятнее и лаконичнее серии вызовов memcpy или других подобных методов обеспечения переносимости.
Можно, конечно, занять позицию максимализма, и объявить любой код, который не допускает быстрого портирования на произвольные платформы, мерзким. Но тогда в категорию "мерзкого" попадают, например, все программы, написанные с использованием MFC или ATL. На мой взгляд, обсуждать всерьёз подобную позицию просто бессмысленно. Вы не согласны?
--
Я думал, ты огромный страшный Бажище,
А ты недоучка, крохотный Бажик...
Здравствуйте, Alexander Shargin, Вы писали:
AS>Можно, конечно, занять позицию максимализма, и объявить любой код, который не допускает быстрого портирования на произвольные платформы, мерзким. Но тогда в категорию "мерзкого" попадают, например, все программы, написанные с использованием MFC или ATL. На мой взгляд, обсуждать всерьёз подобную позицию просто бессмысленно. Вы не согласны?
MFC и ATL/WTL относятся только к части программы — её UI. UI как правило приходится переписывать (или значительно переделывать) при переходе от платформы к платформе, даже если эти платформы — микрософтовские.
Чтобы облегчить портирование программу делят как минимум на 2 части — движок и UI. ИМХО движок имеет смысл писать как можно более кроссплатформенно.
Кроме того, достаточно большой сегмент программ (игры, карты, GPS навигаторы?) имеют кроссплатформенный UI тоже, и следовательно его тоже стоит писать изолируя от платформ специфик...
Здравствуйте, NikeByNike, Вы писали:
NBN>Чтобы облегчить портирование программу делят как минимум на 2 части — движок и UI. ИМХО движок имеет смысл писать как можно более кроссплатформенно.
Ну вот в Плюсе, например, UI почти нет. Ты утверждаешь, что его нужно было делать кроссплатформенным? Или мы всё-таки согласимся, что кроссплатформенность — это просто ещё одна "фича" продукта, которая, в зависимости от специфики этого продукта, рыночных реалий и ещё миллиона причин, может либо требоваться, либо нет?
Если кроссплатформенность требуется, то это диктует ряд проектных решений намного более существенных, чем использование или неиспользование UNALIGNED. Например, имеет смысл отказаться от Win32 при работе с файлами, от EDB как движка БД и от MSXML как парсера XML, и использовать вместо всего этого кроссплатформенные аналоги. Всё это понятно.
Но если кроссплатформенность не требуется, инвестировать в неё — пустая трата времени и денег "здесь и сейчас".
--
Я думал, ты огромный страшный Бажище,
А ты недоучка, крохотный Бажик...
Здравствуйте, Alexander Shargin, Вы писали:
AS>Ну вот в Плюсе, например, UI почти нет. Ты утверждаешь, что его нужно было делать кроссплатформенным?
Нет конечно Плюс — узкоспециазированная утилита. Не находишь, что это сравнительно редкий вид софта?
AS>Или мы всё-таки согласимся, что кроссплатформенность — это всего лишь ещё одна "фича" продукта, которая, в зависимости от реалий рынка, может либо требоваться, либо нет?
ИМХО кроссплатформенность это скорее фича кода, а не продукта. А нужно оно или нет — зависит от стратегии использования кода. Если реиспользование кода не предполагается — то и кроссплатформенность не нужна.
AS>Если кроссплатформенность требуется, то это диктует ряд проектных решений намного более существенных, чем использование или неиспользование UNALIGNED. Например, имеет смысл отказаться от Win32 при работе с файлами, от EDB как движка БД и от MSXML как парсера XML, и использовать вместо всего этого кроссплатформенные аналоги. Всё это понятно.
Дело в том, что для подобных вещей достаточно часто пишут специфичные врапперы облегчающие работу. И в ходе портирования достаточно написать враппер оборачивающий что-то другое.
AS>Но если кроссплатформенность не требуется, инвестировать в неё — пустая трата времени и денег "здесь и сейчас".
ИМХО кроссплатформенность — это скорее культура программирования, она не потребляет специального времени. Покрайней мере — не должна (если с самого начала не ставится задачи сделать софт под несколько платформ). Но например, для тех-же файловых операций или XML — ничего нам не мешает завраппить их для большего удобства использования, делая софт даже для одной платформы. То же касается использования for вместо for each, memcpy вместо UNALIGNED, #if defined вместо pragma once.
Т.е. я не утверждаю, что стоит жилы рвать — когда ещё неизвестно будет ли реиспользован код, но при наличии выбора — лучше сделаю кроссплатформенное решение
Здравствуйте, NikeByNike, Вы писали:
NBN>ИМХО кроссплатформенность — это скорее культура программирования, она не потребляет специального времени. Покрайней мере — не должна (если с самого начала не ставится задачи сделать софт под несколько платформ). Но например, для тех-же файловых операций или XML — ничего нам не мешает завраппить их для большего удобства использования, делая софт даже для одной платформы. То же касается использования for вместо for each, memcpy вместо UNALIGNED, #if defined вместо pragma once. NBN>Т.е. я не утверждаю, что стоит жилы рвать — когда ещё неизвестно будет ли реиспользован код, но при наличии выбора — лучше сделаю кроссплатформенное решение
Я бы всё-таки сказал, что писать кроссплатформенно — это стиль программирования, а не культура. И у этого стиля, как у любого другого, есть свои "за" и "против". Например, если мне нужно описать глобальную переменную в заголовке, я напишу:
__declspec(selectany) int var;
А не:
class CVar
{
static int &GetVar() { static int _var; return _var; }
};
#define var CVar::GetVar()
Просто потому, что первый вариант более лаконичный и понятный.
Другой пример: если я пишу под одну платформу с использованием Win32, я не буду писать врапперы над всеми функциями, которые я использую, просто потому, что это лишний код, в котором могут быть лишние ошибки, которые "проскочут" тестовую фазу и попадут в релиз. Я считаю, что при прочих равных "меньше кода" означает "лучше результат".
Я, естественно, не утверждаю, что моя позиция единственно правильная. Твоя позиция мне вполне понятна, и имеет точно такое же право на существование, как и моя. И вообще, спорить о стилях программирования — бессмысленное занятие. А не согласен я исключительно с категоричной и эмоционально окрашенной оценкой UNALIGNED, которую дал товарищ Handie.
--
Я думал, ты огромный страшный Бажище,
А ты недоучка, крохотный Бажик...
AS>Я, естественно, не утверждаю, что моя позиция единственно правильная. Твоя позиция мне вполне понятна, и имеет точно такое же право на существование, как и моя. И вообще, спорить о стилях программирования — бессмысленное занятие. А не согласен я исключительно с категоричной и эмоционально окрашенной оценкой UNALIGNED, которую дал товарищ Handie.
Вы работаете в конторе которая пишет под одну платформу.
Я работаю в другой конторе и мне приходится крыть матом тех, кто пишет код который был написан "непереносимым".
Код написанный под единственный компилятор и его прибабахи — для меня дерьмо. Да, такой я максималист
AS>Ну вот. Я-то надеялся, что вы нам что-то интересное расскажете. Ну да ладно. AS>А где работаете, если не секрет?
В крупной корпорации, надеюсь что не слишком задержусь.
Признаю что высказывался эмоционально, я сторонник портируемого и надежного кода если нет однозначных причин для обратного. В данном случае эти причины не были озвучены.
В моей жизни очень часто оказывалось что код который "абсолютно точно" написан под одну платформу впоследствии переносился на другие платформы. Наример 90% кода который делается мной под WM компилируется и работает на Win32.
