сопоставление списков, динамическая память Опции

[мисс_граффити]

Что надо сделать: (домучать все те же сети Петри)
Есть списки:
список позиций (содержится инфа: номер (имя) позиции, количество фишек в ней, указатель на след. позицию)
список переходов (номер перехода, указатель на список входящих дуг, указатель на список исходящих)
"навешанные" на него списки дуг (указатель на позицию, которая этой дугой связана с переходом, кратность дуг - для мультиграфа).
соответственно, этот указатель надо вполне конкретно задать.

Что я делаю (работает, но как-то мне такой способ не особо нравится):
1) создаю список позиций
2) начинаю создавать список переходов. для каждого перехода сначала соответствующие списки дуг, а потом их "прикрепляю".
сложность с заданием указателя на позицию в списке.
у меня есть указатель на первую позицию. указатель на вторую получается как first^.next
на третью - (first^.next)^.next
ну, или в цикле... но по сути то же самое.
это как-то оптимизируется?
(если запутано объяснила, могу картинкой нарисовать схему).
спасибо.

[volvo]

Картинка бы не помешала...

Кстати, ты не могла бы привести также и определения типов (всю программу не надо, только сами описания типов, используемые в твоей реализации)?

[мисс_граффити]

Вот структура примерно...
Чисто информационные поля не вырисовывала, только систему связей (что на что ссылается).
То есть, например, в первый переход входит 2 дуги: из первой и второй позиции, а исходит всего одна - во вторую позицию.
Во второй переход входит дуга из второй позиции, а исходит в первую и третью и т.д.
Типы:

Posref = ^Position; //Тип: указатель на позицию
Lref = ^Leader; // Тип: указатель на заголовочный узел перехода
Tref = ^Trailer; //Тип: указатель на дугу
//Описание типа заголовочного узла перехода
Leader=Record
Key : Integer; // Имя заголовочного узла
Trail1 : Tref; //Указатель на список входящих дуг
Trail2 : Tref; //Указатель на список исходящих дуг
Next : Lref // Указатель на следующий узел в списке заголовочных узлов
end;
//Описание типа дугового узла
Trailer = Record
Id : Posref; //Указатель на ту позицию, в/из которой входит/выходит дуга
Count : Integer; //Количество дуг, связывающих эту позицию с переходом
Next : Tref //Указатель на следующую дугу
end;
//Описание типа позиции
Position = Record
Key : Integer;
Next : Posref;
end;

[volvo]

Значит, вопрос в следующем: ты работаешь именно со структурами, или с объектами? Если можно использовать ООП, то все будет гораздо проще реализовать: делаем некий обобщенный список TList, который хранит любую информацию в виде TItem - абстрактного узла (в нем же, кстати, можно сделать и то, что ты выделила как проблему:

Function TList.GetPtr(pos: Integer): PItem;

, возвращающая указатель на нужный элемент списка...
), а уже потом - 3 производных класса от того самого абстрактного узла: TLeaderItem, TTrailerItem и TPositionItem, которые будут хранить то, что именно тебе нужно...

Полиморфизм, так сказать

[мисс_граффити]

ООП в принципе использовать не запрещено (как выражается препод: "Лучшая программа - это та, которая работает"), но в этой конкретной (первой) лабе не желательно. То есть можно при наличии серьезных преимуществ. В том, что я написала на данный момент, ООП не используется, но перестроить не проблема.

А как оно решает проблему-то? Что изменится от того, что я оформлю ф-цию как метод? Внутри-то все равно надо что-то писать... А проблема именно с тем, что то есть с алгоритмом получения указателя.
он сводится к последовательному переходу с одного эл-та списка на другой, пока не дойдем до нужного, или можно как-то по-другому?
меня вот что интересует...

[volvo]

он сводится к последовательному переходу с одного эл-та списка на другой, пока не дойдем до нужного, или можно как-то по-другому?

Нет, по другому со списками нельзя, только последовательным переходом от одного элемента к другому. А проще именно в ООП, потому, что вот сейчас у тебя 3 разных структуры, следовательно, чтобы в каждом из списков перейти к заданному элементу, тебе придется написать 3 разные функции, а если это будет метод родительского (скажем, так) класса, то он унаследуется, и будет работать для любого вида списков

В том, что я написала на данный момент, ООП не используется, но перестроить не проблема.

Это только кажущаяся простота... Перестроить так, чтобы с этим было удобнее работать, чем с не-ООП версией - еще какая проблема...

[мисс_граффити]

мне в других списках только последовательно ходить и надо:
Проверила один элемент, если надо - перешла на следующий... именно такого, чтобы получить указатель на элемент с конкретным номером (именем) - нет. То есть этот метод все равно понадобился бы только при "цеплянии" дуг к вершинам.
Перестроить, чтобы было удобнее работать - сложно, а чтобы "при большом желании можно было работать" - не проблема...