dev

включает в себя  Разработка игр  (+4)  Инструменты разработки   С++

Тестирование и отладка

Пост для самых маленьких. Самые большие могут не читать.

Допустим, вы работаете над программой на С++, которую по мере разработки тестирует другой человек или группа людей.

Допустим, ваша программа с завидной регулярностью валится.

Допустим, это сопровождается не сообщением

«Уважаемый тестер! Программа свалилась по причине того, что разработчик в файле MyFile.cpp, строке 12 написал new char[ strlen( str + 1 ) ] вместо new char[ strlen( str ) + 1 ]. Подскажите разработчику, чтобы он больше так не делал»

а чем-то вроде

(0x80000003) occurred in the application at location 0x0041d12b.

Что делать.

Значит, во-первых: 0x0041d12b – это адрес того места, в котором случилось плохое (это плохое называется «исключением»). Можно попробовать запустить программу в режиме отладки (Step Into) и ручками записать это значение в регистр EIP. Вероятнее всего, при этом отладчик перепрыгнет на ту строчку кода, которая сделала бяку.

Во-вторых: Воспользоваться библиотекой DbgHelp (которая входит в комплект Visual Studio), а точнее функцией MiniDumpWriteDump. В этом месте мне придется прекратить паясничать и называть исключения «какой», так как я совершенно не горю желанием писать развернутый howto для идиотов, не знающих как подключить библиотеку.

В общем, библиотеку нужно подключить, а затем сделать что-то похожее на вот это:

#include <dbghelp.h>
void DumpIt( HANDLE hFile, PEXCEPTION_POINTERS excpInfo)
{
        MessageBox( NULL, "An exception!", "OMG NO", MB_OK | MB_ICONSTOP );
        MINIDUMP_EXCEPTION_INFORMATION eInfo;
        eInfo.ThreadId = GetCurrentThreadId();
        eInfo.ExceptionPointers = excpInfo;
        eInfo.ClientPointers = FALSE;
        MiniDumpWriteDump(
                        GetCurrentProcess(),
                        GetCurrentProcessId(),
                        hFile,
                        MiniDumpNormal,
                        excpInfo ? &eInfo : NULL,
                        NULL,
                        NULL);
}
//...
hDump_File = CreateFile("crash.dmp", GENERIC_WRITE, NULL, CREATE_ALWAYS, 
FILE_ATTRIBUTE_NORMAL, NULL);
__try
{
	// Сюда вписать опасный код. В моем случае - всё приложение.
}
__except(DumpIt(hDump_File, GetExceptionInformation()), 0) {}
CloseHandle(hDump_File);

Удачи в отладке.

Update: А, ну гениально. Самое главное забыл сказать. Вышеприведенный код в случае «падения» запишет в файл hDump_File некоторую информацию, с помощью которой можно более или менее точно восстановить обстоятельства крушения. Этот файл можно открыть студией (Open Project/Solution), нажать F5 — и оказаться в условиях, близких к тем, которые привели к катастрофе. Желательно, чтобы файл имел расширение .dmp, это облегчит студии понимание, что ей пытаются всучить.

Ссылка по теме: Статья на английском с примерами. Кроме самой функции MiniDumpWriteDump в статье (и примерах) много лишней ерунды, зато примеры компилируются и работают. Sapienti sat, всё такое.

Web-интерфейсы

Несколько банальных утверждений.

Web-интерфейс нужен тогда, когда существует проблема доставки клиентского кода на целевую машину. Например, web-интерфейс к почтовому сервису может оказаться полезным в тех редких случаях, когда необходимо прочесть почту с компьютера, который вам не принадлежит, и которым вы пользуетесь один раз: в интернет-кафе или в гостях. У себя дома или в офисе вы, вероятно, установите «стационарный» почтовый клиент. Это гораздо удобней.

Человек, который набирает в Semagic пост о повсеместном применении в ближайшем светлом будущем web-интерфейсов (AJAX etc.), выглядит, по меньшей мере, забавно. Именно поэтому он прав – все известные мне пророчества светлого будущего, которым было суждено сбыться, озвучивались при схожих забавных обстоятельствах. Это единственный аргумент в пользу светлого будущего AJAX, который у меня есть. «Это выглядит глупо, а значит похоже на правду».

Особенно продвинутые визионеры объединяют в одном видении светлого будущего два, в общем-то, антагонистичных по отношению друг к другу подхода – AJAX и RSS. Это еще больше похоже на правду. По тем же соображениям.

Можно предположить, что такая горячая поддержка web-приложений и сервисов вызвана популярным заблуждением, что web-приложения писать проще. Это не так, если вы этого не понимаете, значит, вы программист на PHP.

Еще раз: На сегодняшний день, при существующем уровне развития технологий, web-интерфейс к чему-либо, это такой легковесный заменитель полноценного приложения, который имеет, с точки зрения пользователя, единственное преимущество: легкость в доставке на целевую машину. Все остальные качества web-интерфейса – недостатки.

Извините, что пишу очевидные вещи.

Архитекторы

Системный архитектор в маленькой вебстудии, это как штатный физик-ядерщик в автомастерской.

И, что самое замечательное, помидоры в меня не полетят, так как на этом сайте 50 постоянных читателей, ни один из которых не является системным архитектором в маленькой вебстудии. Замечательно, не так ли?

Женщина, которая сделала sigslot

Вот эта женщина, а вот её sigslot.

Если вам по каким-то причинам не нравится Boost (лично у меня таких причин — масса), но хочется сигналов/слотов — sigslot — хорошая альтернатива.

HGE

Вот пример того, что я называю удобной архитектурой. Ноги там, насколько я пониманию, растут из Grim 2D — движка Crimsonland.

Не без мелких ляпов, конечно, но куда же без них.

HGE, кстати говоря, стал совсем бесплатным. Одно из лучших (если не лучшее) решений для быстрого прототипирования и разработки shareware игр. Скажем спасибо дяде Haaf’у за наше счастливое детство.

Смотри также:
How to Prototype a Game in Under 7 Days

ООП

По поводу ООП, PHP и прочего, имею что сказать.

За два года я убедился, что спорить с людьми о подобных вещах — только портить себе же нервы. Всегда находятся профессионалы и знатоки, у которых в запасе есть много слов, начинающихся с мета- и английских аббревиатур — на случай, если покажется мало. Для вдумчивой аргументации, надо полагать.

В какой-то момент до меня дошло, что я не обязан отстаивать свои убеждения перед кучкой идейных фанатиков. Это они, а не я, будут создавать для «болтающихся» процедур классы, состоящие исключительно из статичных членов, а затем удивляться, почему добавление еще одного частного статичного поля вызывает пересборку всего проекта. Это они, а не я, будут создавать XML-driven framework там, где нужна одна красная кнопка в центре экрана. Они, а не я добровольно усложняют себе жизнь.

Так чего спорить? Let ’em be. Тем более, что мудаков, получающих удовольствие от разжигания межконцептуальной розни и так хватает.

Dixi.

Lua 5.1 + Direct3D

Памятка пользователям Lua 5.1 и Direct3D:

При создании устройства необходимо обязательно поднимать флаг D3DCREATE_FPU_PRESERVE. Иначе всему пиздец. Только что с этим столкнулся.

A warning for users of DirectX/Direct3D: You MUST set the
D3DCREATE_FPU_PRESERVE flag upon initialization when you
use Lua in the same thread. Otherwise you’ll encounter
strange behaviour -- complain to Microsoft, not to us.

( источник )

«Как заставить неправильный код выглядеть неправильно»

Перевод хорошей статьи Joel’а про вещи, которые, в общем-то, самоочевидны и интуитивно-понятны, но только выигрывают от удачной формулировки.