Переменные и методы класса выдают ошибку компиляции
Модератор: Модераторы
- Лекс Айрин
- долгожитель
- Сообщения: 5723
- Зарегистрирован: 19.02.2013 16:54:51
- Откуда: Волгоград
- Контактная информация:
zub, похоже, если в 3Д, то картина будет занимательная.
Картинка и в 2Д занимательная))
Вариант с построением от узлов-юнитов:

Проблемные юниты помечаются как учавствующие в циклах, и в граф попадают они и все ребра выходящие\приходящие из\в них. На картинке проблемные юниты, проблемные ребра и некоторое количество непроблемных ребер попавших сюда за компанию. Сказать чтото глядя на картинку трудно, только то что полная жопа))
Вариант с построением от проблемных ребер:

Общий граф анализируется на предмет зацикливаний, потом перебираются все ребра и если ребро участвует в цикле - выводится ребро и юниты которые оно соединяет. Пока этот момент недоделан - ребра не "раскрашены" в зависимости от интерфейс это или имплементация. На картинке ничего лишнего, только проблемные юниты и проблемные зависимости этих юнитов. Зная чуток архитектуру программы, глядя на эту картинку можно многое сказать.
Присутствует 4 проблемный "узла"
1 "узел" - нужно избавиться от зависимости uzcshared->uzcfcommandline и узелок распадется. uzcshared раньше был в implementatin uses почти всех модулей зкада и предоставлял общие процедуры записи в лог, сообщений об ошибках и т.п. Потом я с ним долго и упорно боролся, но до конца чуток недоборол.
2 "узел" - очень проблемное место. uzeentity - класс базового примитива, UGDBSelectedObjArray, UGDBOpenArrayOfPV, UGDBVisibleOpenArray - разные варианты массивов примитивов. Тут прибется поломать голову как разрулить\минимизировать зависимости.
3 "цикл" из 2х модулей - эти сущности друг без друга существовать не могут, поэтому разделены на 2 разных юнита только для моего удобства, по сути это "монолит"
4 ленивый "замес" гуйни)) чтото наподобии как в lexeditor. Некрасиво конечно, но есть более насущные проблемы.
Вобщем получился мощьный инструмент для говнокодеров типа меня - можно красиво ворочить мешки с какашками)) Если программа состоит >50 модулей - такие картинки очень полезны, если меньше то можно и только головой обойтись.
Если кому интересно бинарник http://sourceforge.net/projects/zcad/fi ... z/download
Жмем Import LPI - импортируем настройки лазаревского проекта. если в путях присутствуют макросы то их придется руками "раскрыть" в инспекторе
Scan - сканирование исходников, получение репорта о циклах, и графа циклов. Настройки построения графа в инспекторе на граф циклов пока невлияют
Save - получение графа согласно настроек.
Если будут проблемы с парсеньем исходников - отписываемся. Пока неполучилось подружить парсер с индексацией чегобы то нибыло в скобках, например конструкция (StringVar)[10] - приведет к вылету
Вариант с построением от узлов-юнитов:
Проблемные юниты помечаются как учавствующие в циклах, и в граф попадают они и все ребра выходящие\приходящие из\в них. На картинке проблемные юниты, проблемные ребра и некоторое количество непроблемных ребер попавших сюда за компанию. Сказать чтото глядя на картинку трудно, только то что полная жопа))
Вариант с построением от проблемных ребер:
Общий граф анализируется на предмет зацикливаний, потом перебираются все ребра и если ребро участвует в цикле - выводится ребро и юниты которые оно соединяет. Пока этот момент недоделан - ребра не "раскрашены" в зависимости от интерфейс это или имплементация. На картинке ничего лишнего, только проблемные юниты и проблемные зависимости этих юнитов. Зная чуток архитектуру программы, глядя на эту картинку можно многое сказать.
Присутствует 4 проблемный "узла"
1 "узел" - нужно избавиться от зависимости uzcshared->uzcfcommandline и узелок распадется. uzcshared раньше был в implementatin uses почти всех модулей зкада и предоставлял общие процедуры записи в лог, сообщений об ошибках и т.п. Потом я с ним долго и упорно боролся, но до конца чуток недоборол.
2 "узел" - очень проблемное место. uzeentity - класс базового примитива, UGDBSelectedObjArray, UGDBOpenArrayOfPV, UGDBVisibleOpenArray - разные варианты массивов примитивов. Тут прибется поломать голову как разрулить\минимизировать зависимости.
3 "цикл" из 2х модулей - эти сущности друг без друга существовать не могут, поэтому разделены на 2 разных юнита только для моего удобства, по сути это "монолит"
4 ленивый "замес" гуйни)) чтото наподобии как в lexeditor. Некрасиво конечно, но есть более насущные проблемы.
Вобщем получился мощьный инструмент для говнокодеров типа меня - можно красиво ворочить мешки с какашками)) Если программа состоит >50 модулей - такие картинки очень полезны, если меньше то можно и только головой обойтись.
Если кому интересно бинарник http://sourceforge.net/projects/zcad/fi ... z/download
Жмем Import LPI - импортируем настройки лазаревского проекта. если в путях присутствуют макросы то их придется руками "раскрыть" в инспекторе
Scan - сканирование исходников, получение репорта о циклах, и графа циклов. Настройки построения графа в инспекторе на граф циклов пока невлияют
Save - получение графа согласно настроек.
Если будут проблемы с парсеньем исходников - отписываемся. Пока неполучилось подружить парсер с индексацией чегобы то нибыло в скобках, например конструкция (StringVar)[10] - приведет к вылету
Последний раз редактировалось zub 22.09.2016 20:11:27, всего редактировалось 3 раза.
- Лекс Айрин
- долгожитель
- Сообщения: 5723
- Зарегистрирован: 19.02.2013 16:54:51
- Откуда: Волгоград
- Контактная информация:
zub писал(а): ленивый "замес" гуйни)) чтото наподобии как в lexeditor.
там это только из-за прямого доступа к редактору -- по сути оптимизация. Переделать-то не сложно... но увеличиваются накладные расходы на таймер и в каждый модуль придется добавлять буфер. А ты сам говорил, что таймер должен быть маленьким и шустрым.
zub писал(а): "цикл" из 2х модулей - эти сущности друг без друга существовать не могут, поэтому разделены на 2 разных юнита только для моего удобства, по сути это "монолит"
А если один модуль переделать в inc-файл.
zub писал(а):ленивый "замес" гуйни)) чтото наподобии как в lexeditor. Некрасиво конечно, но есть более насущные проблемы.
Это как раз не сильно сложная проблема -- морду в дизайнере нарисовать легко. Только, имхо, пока не слишком надо. Лично я начинал не от кода, а как-раз от морды. Это немножко другой подход программирования.
Добавлено спустя 24 минуты 30 секунд:
Ах да... небольшая странность... почему в lexeditor целевая ось линукс, если я программирую (и собираю) под виндой, а прога кроссплатформенная?
Лекс Айрин
импортируются настройки путей. платформа и проц захардкожены в таком виде.
импортируются настройки путей. платформа и проц захардкожены в таком виде.
- Лекс Айрин
- долгожитель
- Сообщения: 5723
- Зарегистрирован: 19.02.2013 16:54:51
- Откуда: Волгоград
- Контактная информация:
zub, понятно.
"раскрасил" связи в графе "зацикленности". как и предпологалось большинство зависимостей из implementation uses

добавил небольшой отчет по графу. вот то что выдается по зкаду:
добавил небольшой отчет по графу. вот то что выдается по зкаду:
Код: Выделить всё
Total units: 349 - всего юнитов в графе включая lcl, fpc и другие не принадлежащие проекту
Total founded units: 244 - всего юнитов с найеными исходниками - скорее всего принадлежащие проекту
Total units with Implimentation uses: 63 - юнитов с зависимостями в implementation uses
Total units in loops: 43 - юнитов участвующих в "циклах"
Total dependencies: 3697 - всего связей
Total dependencies in loops: 112 - связей участвующих в циклах
Implimentation uses can be move to interface in uzclog, uzcsysinfo, uzcguimanager, UGDBPoint3DArray, uzgloglstatemanager, uzeentdevice, uzeentdimension, uzcregother, uzeffttf, uzegluinterface, uzeentdimensiongeneric, uzeentdimaligned, uzcentnet, UGDBGraf, uzeentlwpolyline, uzcdevicebaseabstract, uzcdevicebase, uzcfprojecttree, uzcctrlcontextmenu, uzccommandsimpl, uzctextenteditor, zcobjectchangeundocommand2, uzcfabout, uzcfhelp, uzcctrllayercombobox, uzccomdb, uzccomdraw, uzccomdrawdase, uzeenttable, uzcprinterspecfunc, uzcentcable, uzccomelectrical, uzcentelleader, uzccablemanager, uzccomops, uzctextpreprocessorimpl, uzclibraryblocksregister; - перечень юнитов implementation uses которых можно безболезнено перенести в interface
Последний раз редактировалось zub 22.09.2016 19:40:40, всего редактировалось 1 раз.
- Лекс Айрин
- долгожитель
- Сообщения: 5723
- Зарегистрирован: 19.02.2013 16:54:51
- Откуда: Волгоград
- Контактная информация:
zub, немного странная картина... по идее, в реализации должно быть только замыкание цикла.
В проекте больше двухсот файлов, я это всё и затеял чтобы навести порядок в усесах
- Лекс Айрин
- долгожитель
- Сообщения: 5723
- Зарегистрирован: 19.02.2013 16:54:51
- Откуда: Волгоград
- Контактная информация:
да это как раз понятно... удачи. Собственно, так и начинались многие проекты... чисто для себя, чтобы что-то поудобнее сделать. Собственно, я и сам собираюсь пользоваться. В том числе, возможно, и как часть будущих проектов.
Лекс Айрин
Ты был прав - баг. поправил последнюю картинку, сплошных линий гораздо больше. после имен юнитов сооответственно колво ссылок в interface_implementation uses
Ты был прав - баг. поправил последнюю картинку, сплошных линий гораздо больше. после имен юнитов сооответственно колво ссылок в interface_implementation uses
- Лекс Айрин
- долгожитель
- Сообщения: 5723
- Зарегистрирован: 19.02.2013 16:54:51
- Откуда: Волгоград
- Контактная информация:
zub, чисто доверие к профессионализму -- во первых, мало кто вообще с ходу знает о возможности подключения модулей в разделе реализации, а во вторых нет смысла туда пихать модули если в интерфейсной части спокойно подключается.
>>а во вторых нет смысла туда пихать модули если в интерфейсной части спокойно подключается.
Оно писалось не за раз, а очень долго. по пути переписывалось с ног на голову. Раньше можно было только в имплементации, изменил чтото в другом месте - стало можно в интерфейсе. Еслиб фпц давал варнинги по этому поводу...
Оно писалось не за раз, а очень долго. по пути переписывалось с ног на голову. Раньше можно было только в имплементации, изменил чтото в другом месте - стало можно в интерфейсе. Еслиб фпц давал варнинги по этому поводу...
- Лекс Айрин
- долгожитель
- Сообщения: 5723
- Зарегистрирован: 19.02.2013 16:54:51
- Откуда: Волгоград
- Контактная информация:
Я же не спорю... и потом, если уж в исходниках fpc варнингов туева хуча, то что же говорить о нас грешных?
Я не понял строчку " lexeditor [shape=box]" -- к чему она относится? В yEd вроде бы нет ни такого значения, ни такого раздела.
Зы: я, как закончу,организую временную кнопочку для проверки? А то подменять работающий функционал ломает.
Я не понял строчку " lexeditor [shape=box]" -- к чему она относится? В yEd вроде бы нет ни такого значения, ни такого раздела.
Зы: я, как закончу,организую временную кнопочку для проверки? А то подменять работающий функционал ломает.
>>lexeditor [shape=box]
Для program в графе создается квадратик, для unit - овал - он поумолчанию
>> как закончу,организую временную кнопочку для проверки? А то подменять работающий функционал ломает.\
конечно. ты вообще свой модуль организуй, uwriter пусть пока будет такой как есть
Для program в графе создается квадратик, для unit - овал - он поумолчанию
>> как закончу,организую временную кнопочку для проверки? А то подменять работающий функционал ломает.\
конечно. ты вообще свой модуль организуй, uwriter пусть пока будет такой как есть
- Лекс Айрин
- долгожитель
- Сообщения: 5723
- Зарегистрирован: 19.02.2013 16:54:51
- Откуда: Волгоград
- Контактная информация:
zub писал(а):Для program в графе создается квадратик, для unit - овал - он поумолчанию
ок. то есть, для меня это rectangle и ellipse соответственно...
zub писал(а):ты вообще свой модуль организуй, uwriter пусть пока будет такой как есть
не вопрос... для меня это, в принципе, дело 5-10 минут. Мне так даже легче.
