Парсер inline-ассемблера на С++
 

:) Вот такая задача передо мной встала: в короткий срок разработать его.... Разрабатываю второй месяц - написал кучу кода
Просьба античаовцам: посмотреть его (желательно на MS Visual Studio 6) и общее мнение высказать, ну и помочь справиться с:
а) лики детектед) Их бы убрать)
б) оптимизировать наконец этого монстра)))

Собственно код в ZIP архиве Исправил ссыль тута)

Да кстати) будет дорабатываться и выкладываться сюда довольно активно))))
И... я понимаю конечно что просматривать все это - думалка сломается, но пожалуйста, просмотрите это, что не понятно зачем - спрашивайте))))

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

Ну и залил архив на обменник, где регистрация не требуется.

Виноват - исправлюсь)))
Сцыль на Яндексовском народе)

Код брутален. Сильно не смотрел, хватило моментов вроде
Не сразу понял, что класс наследует структуру, которая таким образом обнуляется.
А еще кучка goto. По-моему, с объектно-ориентированным подходом goto как-то слишком.
Если была задача разработать в короткий срок - можно было бы использовать регулярные выражения, было бы гораздо быстрее и меньше кода.

Пару слов про этот класс, CLexeme
1. Зачем у него публичный метод Init()? Сюдя по названию (рискну предположить, что Init здесь означает инициализацию, а не сброс состояния, к примеру, т.к. тогда его было бы логично назвать Reset()), так вот, сюдя по названию, он нужен для инициализации экземпляра этого класса, так какой смысл выносить его в отдельный метод? Перенеси его код в конструктор - меньше вероятность, что при каких-либо переделках случайно словишь баг.

2. Собственно тело метода Init(). Вот это:
тихий ужас. Ладно бы так было:
Понятно, что в твоем коде работают оба варианта, но они работают ровно до тех пор, пока ты не добавишь еще одно поле, но в класс 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) хорошо удалю комментарии *лишние* и выложу)
Новое - читабельное =)

Замечу, что рассматривайте пожалуйста именно parser.h и parser.cpp =)

3) switch?

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

бнф - вот:
Собственно препод ее еще не дорабоотал)
Грамматика(DOC)
По коду вообще ну поищите где лики берутся) И по парсеру - его как оптимизировать)

лики тестятся специальным флагом CRT, но так как вы заменяете управление памятью своим монстром, встроенные средства юзать не получится. а на глаз лики никто не ищет.

поэтому и не пользуюсь HeapAlloc HeapReAlloc так как в случае с malloc realloc я могу
использовать отладочные их версии и в конце программы вызвать _CrtDumpMemoryLeaks();
что покажет мне все лики вплоть до строчки выделения памяти которая не освобождена была для не больших проектов прекрасно помогает а в первом случае для системных апи придется втыкать самостоятельно и сто процентов не найдеш все лики
_CrtMemState ms;
_CrtMemDumpAllObjectsSince(&ms);
/// много кода интенсивно работающего с памятью
_CrtDumpMemoryLeaks();
это для поиска ликов на отдельных участках программы интенсивно оперирующих с памятью

весь вывод об ликах печатается через OutputDebugString в окне Output отладчика

вернее так для мониторинга участков программы
_CrtMemState ms;
_CrtMemCheckpoint(&ms);
/// тут много кода с вызовами malloc realloc free
_CrtMemDumpAllObjectsSince(&ms);
или если для всей программы смотреть перед выходом из main или WinMain перед return можно вставить один вызов _CrtDumpMemoryLeaks(); и все