Просмотр полной версии : Парсер inline-ассемблера на С++
:) Вот такая задача передо мной встала: в короткий срок разработать его.... Разрабатываю второй месяц - написал кучу кода
Просьба античаовцам: посмотреть его (желательно на MS Visual Studio 6) и общее мнение высказать, ну и помочь справиться с:
а) лики детектед) Их бы убрать)
б) оптимизировать наконец этого монстра)))
Собственно код в ZIP архиве (http://narod.ru/disk/21853699000/140610.zip.html) Исправил ссыль тута)
Да кстати) будет дорабатываться и выкладываться сюда довольно активно))))
И... я понимаю конечно что просматривать все это - думалка сломается, но пожалуйста, просмотрите это, что не понятно зачем - спрашивайте))))
AlexTheC0d3r
14.06.2010, 22:38
Да кстати) будет дорабатываться и выкладываться сюда довольно активно))))
И... я понимаю конечно что просматривать все это - думалка сломается, но пожалуйста, просмотрите это, что не понятно зачем - спрашивайте))))
сразу бы написал для не понимающий зачем, и что это такое
сразу бы написал для не понимающий зачем, и что это такое
Ну и залил архив на обменник, где регистрация не требуется.
Виноват - исправлюсь)))
Сцыль на Яндексовском народе) (http://narod.ru/disk/21853699000/140610.zip.html)
Код брутален. Сильно не смотрел, хватило моментов вроде
AFX_INLINE void CLexeme::Init()
{
memset(this, 0, sizeof(LEXEME));
Не сразу понял, что класс наследует структуру, которая таким образом обнуляется.
А еще кучка goto. По-моему, с объектно-ориентированным подходом goto как-то слишком.
Если была задача разработать в короткий срок - можно было бы использовать регулярные выражения, было бы гораздо быстрее и меньше кода.
Пару слов про этот класс, CLexeme
1. Зачем у него публичный метод Init()? Сюдя по названию (рискну предположить, что Init здесь означает инициализацию, а не сброс состояния, к примеру, т.к. тогда его было бы логично назвать Reset()), так вот, сюдя по названию, он нужен для инициализации экземпляра этого класса, так какой смысл выносить его в отдельный метод? Перенеси его код в конструктор - меньше вероятность, что при каких-либо переделках случайно словишь баг.
2. Собственно тело метода Init(). Вот это:
memset(this, 0, sizeof(LEXEME));
тихий ужас. Ладно бы так было:
memset(this, 0, sizeof(CLexeme));
Понятно, что в твоем коде работают оба варианта, но они работают ровно до тех пор, пока ты не добавишь еще одно поле, но в класс CLexeme. Хотя, вообще говоря, 5 полей класса очистить проще вручную.
3. Вообще мне не ясен смысл класса CLexeme - он же просто расширяет LEXEME парой методов. Не проще ли их объединить в один класс?
Остальное даже смотреть не стал - обилие закомменченых строк кода, куча адский enum'ов без единой строчки описания, короче, хрен разберешься.
Мой скромный совет - отрефакторить код до читабельного состояния, потом - найти и исправить утечки, и только потом - заниматься оптимизацией.
PS: Шпаргалка с исходником в архиве улыбнула :)
((*pPos == ' ') || (*pPos == '\t') || (*pPos == 13) || (*pPos == 10) ) ) -> http://www.cplusplus.com/reference/clibrary/cctype/isspace/
куча апишек для работы с файлом. -> http://www.cplusplus.com/reference/iostream/fstream/
выделение памяти и освобождение повергло в глубокий шок. Это что там вообще такое? -> http://www.cplusplus.com/reference/std/new/
Куча дефайнов тоже умиляет. -> http://programmersclub.ru/15/
про гото уже сказали.
Куски кода типа
if (*pPos == '<')
{
Token.Buffer = pPos;.....
в огромном количестве заменяются на вызовы методов, дабы уменьшить длину простыни одного метода.
if (*pPos == '<')
{
lexemLess();
Можешь даже сделать через switch, тогда получишь оптимизацию в виде поиска за один шаг, вместо прохода всего списка лексем.
Комменты со старым кодом лучше удалять, отвлекают. Если ссыкатно повредить код - используй svn. Очень легко и удобно.
Ах да, еще велосипедный лист =) -> http://www.cplusplus.com/reference/stl/list/
Спасибо) Собственно отвечу
1 Класс CLexem вводили на паре и я, как видно его нигде не использую... Зачем его ввели я не понял и сам, а удалять пока не хочется)
2 Выделение и освобождение памяти - тоже писали на паре и препод попросил именно через эти функции работать. Этот блок работает верон - 100% отлаживался дофига на разных примерах
3 Goto - ну предложите как без него. И потом - оно всего одно по сути в одном месте - думаю понятен его смысл)
4) хорошо удалю комментарии *лишние* и выложу)
Новое - читабельное =) (http://narod.ru/disk/21867761000/150610.zip.html)
Замечу, что рассматривайте пожалуйста именно parser.h и parser.cpp =)
3) switch?
по остальному хз. бнф не видно. но код не сказать что кривой, вполне нормальный.
бнф - вот:
Собственно препод ее еще не дорабоотал)
Грамматика(DOC) (http://narod.ru/disk/21889146000/%D0%93%D1%80%D0%B0%D0%BC%D0%BC%D0%B0%D1%82%D0%B8%D 0%BA%D0%B0%20inline-ASM%2B%2B.doc.html)
По коду вообще ну поищите где лики берутся) И по парсеру - его как оптимизировать)
лики тестятся специальным флагом CRT, но так как вы заменяете управление памятью своим монстром, встроенные средства юзать не получится. а на глаз лики никто не ищет.
greki_hoy
16.06.2010, 04:05
поэтому и не пользуюсь HeapAlloc HeapReAlloc так как в случае с malloc realloc я могу
использовать отладочные их версии и в конце программы вызвать _CrtDumpMemoryLeaks();
что покажет мне все лики вплоть до строчки выделения памяти которая не освобождена была для не больших проектов прекрасно помогает а в первом случае для системных апи придется втыкать самостоятельно и сто процентов не найдеш все лики
_CrtMemState ms;
_CrtMemDumpAllObjectsSince(&ms);
/// много кода интенсивно работающего с памятью
_CrtDumpMemoryLeaks();
это для поиска ликов на отдельных участках программы интенсивно оперирующих с памятью
greki_hoy
16.06.2010, 04:09
весь вывод об ликах печатается через OutputDebugString в окне Output отладчика
greki_hoy
16.06.2010, 12:40
вернее так для мониторинга участков программы
_CrtMemState ms;
_CrtMemCheckpoint(&ms);
/// тут много кода с вызовами malloc realloc free
_CrtMemDumpAllObjectsSince(&ms);
или если для всей программы смотреть перед выходом из main или WinMain перед return можно вставить один вызов _CrtDumpMemoryLeaks(); и все
vBulletin® v3.8.14, Copyright ©2000-2026, vBulletin Solutions, Inc. Перевод: zCarot