Что надо сделать: (домучать все те же сети Петри)
Есть списки:
список позиций (содержится инфа: номер (имя) позиции, количество фишек в ней, указатель на след. позицию)
список переходов (номер перехода, указатель на список входящих дуг, указатель на список исходящих)
"навешанные" на него списки дуг (указатель на позицию, которая этой дугой связана с переходом, кратность дуг - для мультиграфа).
соответственно, этот указатель надо вполне конкретно задать.
Что я делаю (работает, но как-то мне такой способ не особо нравится):
1) создаю список позиций
2) начинаю создавать список переходов. для каждого перехода сначала соответствующие списки дуг, а потом их "прикрепляю".
сложность с заданием указателя на позицию в списке.
у меня есть указатель на первую позицию. указатель на вторую получается как first^.next
на третью - (first^.next)^.next
ну, или в цикле... но по сути то же самое.
это как-то оптимизируется?
(если запутано объяснила, могу картинкой нарисовать схему).
спасибо.
Картинка бы не помешала...
Кстати, ты не могла бы привести также и определения типов (всю программу не надо, только сами описания типов, используемые в твоей реализации)?
Вот структура примерно...
Чисто информационные поля не вырисовывала, только систему связей (что на что ссылается).
То есть, например, в первый переход входит 2 дуги: из первой и второй позиции, а исходит всего одна - во вторую позицию.
Во второй переход входит дуга из второй позиции, а исходит в первую и третью и т.д.
Типы:
Значит, вопрос в следующем: ты работаешь именно со структурами, или с объектами? Если можно использовать ООП, то все будет гораздо проще реализовать: делаем некий обобщенный список TList, который хранит любую информацию в виде TItem - абстрактного узла (в нем же, кстати, можно сделать и то, что ты выделила как проблему:
Function TList.GetPtr(pos: Integer): PItem;, возвращающая указатель на нужный элемент списка...
ООП в принципе использовать не запрещено (как выражается препод: "Лучшая программа - это та, которая работает"), но в этой конкретной (первой) лабе не желательно. То есть можно при наличии серьезных преимуществ. В том, что я написала на данный момент, ООП не используется, но перестроить не проблема.
А как оно решает проблему-то? Что изменится от того, что я оформлю ф-цию как метод? Внутри-то все равно надо что-то писать... А проблема именно с тем, что то есть с алгоритмом получения указателя.
он сводится к последовательному переходу с одного эл-та списка на другой, пока не дойдем до нужного, или можно как-то по-другому?
меня вот что интересует...
мне в других списках только последовательно ходить и надо:
Проверила один элемент, если надо - перешла на следующий... именно такого, чтобы получить указатель на элемент с конкретным номером (именем) - нет. То есть этот метод все равно понадобился бы только при "цеплянии" дуг к вершинам.
Перестроить, чтобы было удобнее работать - сложно, а чтобы "при большом желании можно было работать" - не проблема...