Ну вот и отличненько =) Тока вот я и говорю нагромождение ключей, в остальном я согласен! Я попрошу Дениса отписаться по поводу argtable, и как это можно реализовать по красивее.
14 мая 2010 г. 12:01 пользователь Fedor Korshunov < [email protected]> написал: > Артем, Андрей, > > Насчет strip-ов у меня возникла похожая идея что и у Артема: > --strip-call all|file|line|param > --strip-def all|file|return|line|param > --strip-imp all|file|return|line|param > --strip-all > > В принципе у Темы более здравая идея, но непонятно поддерживает ли argtable > (и, что очень важно всяческие GNU/POSIX соглашения) количество аргументов > больше чем 2? > > 2010/5/13 Артём Шапоренко <[email protected]> > >> Решение на мой взгляд достаточно простое, добавляется ключ --strip и к >> нему добавляются параметры, собственно что мы strip и где. >> Например: --strip call - в вызовах >> --strip def call - вызовах и дефинишенах >> и т.д. >> >> 2010/5/13 Андрей Лапин <[email protected]> >> >> *1) Проблема с парсером по обработке указателей:* >>> - на ОС Linux и под Cygwin на windows все отлично работает. >>> - при работе с компилятором cl либо со студией, что одно и тоже при >>> сборке вылетают warning-и ( в приложении log-file сборки ), но они оказались >>> не критичными >>> пока я в свой CmakeList файл не прописал это, собрать не удавалось >>> вообще ( подсмотрел в cmake листе для сборки SA ): >>> >>> if( MSVC ) >>> add_definitions( -D__MSVC__ ) >>> add_definitions( -D_SECURE_SCL_THROWS ) >>> endif( MSVC ) >>> >>> if( WIN32 ) >>> add_definitions( -D__WIN32__ ) >>> # for parsers only >>> add_definitions( -DYY_NO_UNISTD_H ) >>> endif( WIN32 ) >>> >>> В итоге сейчас прблем со сборкой и работой синтаксического анализатора >>> уже нет (если не считать warning-ов с которыми я постараюсь справиться но >>> позже) >>> Проблема появилась при работе ядра для обработки собранных данных. >>> Вылетает exception при релизной сборке, при дебажной получаю вот такую вещь >>> (в скригшоты в приложении). >>> Таким образом я нашел где у меня программа выбрасывает exception но пока >>> не разобрался как это исправить, я даже удивляюсь почему все правильно >>> работает на Linux OS (gcc/g++ 4.x). >>> >>> *Планы на неделю:* >>> - Получить работоспособную версию парсера под windows (пока что под VS >>> компилятор - cl) >>> * >>> 2) Идеологические разногласия с Федей.* >>> --strip-file >>> --strip-line >>> --strip-param >>> --strip-return >>> *--strip-all >>> Задача: * >>> добавить функционал для отключения дополнительной информации в вызовах >>> (call-ах) >>> в данном случае, line, file, params. >>> >>> *Решение предложенное Федей:* >>> добавить выше описанные 5 ключей, ну и соответственно понятно что они >>> делают. >>> Но, эти ключи по его мнению должны распространяться не только на call-ы >>> но и на impl/definition. >>> **--strip-file ( откл file у call/impl/def ) >>> --strip-line ( откл line у call/impl/def ) >>> --strip-param ( откл параметры у call/impl/def ) >>> --strip-return ( отключаем type у impl/def ) >>> *--strip-all* >>> ** >>> (Федя: если я не правильно тебя понял, прошу поправь) >>> * >>> Проблема: * >>> стоит ли распространять функциональность этих ключей на impl/def. >>> Я предполагал что они будут относится только к call-ам. >>> >>> Т.е. impl/def - можно вынести в отдельный функционал. Но тогда мы получим >>> нагромождение ключей с похожими действиями ^_^ (что не приятно) >>> Есть также вопрос к Артему, "Устроит ли это заказчика?" >>> * >>> Я исхожу на данный момент из следующей комической ситуации:* >>> заказчик использует ключ *--strip-all, *но вместо отключения информации >>> в call-ах, она отключается во всем CallGraph. Те получает не совсем то что >>> хотел. >>> Таким образом есть вопрос к Артему, так как он выступает со стороны >>> заказчика, если это его устраивает то почему бы и нет. >>> >>> Жду комментариев, надеюсь я вас не утомил ^_^ >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "SourceAnalyzer Team" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<sa_team%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/sa_team?hl=en. >>> >> >> >> >> -- >> Regards, Artem >> >> tel. +79200444558 >> icq 269910037 >> skype artem.shaporenko >> Source Analyzer Team >> >> -- >> You received this message because you are subscribed to the Google Groups >> "SourceAnalyzer Team" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<sa_team%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/sa_team?hl=en. >> > > > > -- > Best Regards, > Fedor Korshunov > > -- > You received this message because you are subscribed to the Google Groups > "SourceAnalyzer Team" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<sa_team%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/sa_team?hl=en. > -- Andrew Lapin -- You received this message because you are subscribed to the Google Groups "SourceAnalyzer Team" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sa_team?hl=en.
