OberonCore

Что-то давненько не приходилось работать со списком, когда добавлять надо в конец.
Разбаловался системщиной, где один указатель - и добавление в голову )

Так вот, кажется громоздким IF, проверяющий при добавлении список на непустоту.

Разумно принять, что первый элемент списка - фиктивный, пустой.

Например:



Тогда при создании списка:
NEW(list.dummy); list.last := list.dummy;
а при добавлении очередного элемента:
list.last.next := new; list.last := new;

Ну а голова списка - list.dummy.next.
Проверка на пустоту: list.last = list.dummy.

В смысле?

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

Интересно, не появится ли проблем или противоречий, если в языке разрешить следующее присваивание с охраной типа:
dest := source (DestType);
при source = NIL? В таком случае присваивание эквивалентно "dest := NIL", но Оберон выдаёт трап при попытке проверить тип sourcre.

Тогда явная проверка на NIL заменится на скрытую от программиста. В Виртовской Школе считается, что компилятор должен выполнять лишь такие действия, которые сам программист сделать не может. Проверить указатель на NIL программист может и сам, если захочет.

Ну, если у нас список - first и last, то при добавлении:

IF last # NIL THEN
last.next := new; last := new
ELSE
first := new; last := new
END

(На эту громоздкость и Вирт в книге жалуется, типа "удобнее в начало списка").

А если у меня наполнение списка идёт много где - да, например, в цикле - не одного, а нескольких списков.. То этот IF становится поперёк...

Кстати, если список наполняется единожды, а потом передаётся как есть, то передавать стоит просто указатель на элемент. (В моём примере функции у меня возвращают Word, но внутри, в порождающих циклах, работают с WordList).

Используем "барьер" (sentinel) -- и что?
Чётто не понимаю пафоса.
Ну и ладно.

Не, барьер - это в конце, и инициализируемый перед обработкой. А тут - фиктивный элемент в начале, чтобы проверки на NIL избежать. Ну да, полностью аналогично sentinel, но наоборот.

И пафоса нет. Просто поделился нюансом.

Один хрен.

Пафоса оказалось достаточно, чтобы начать тему.

Просто любопытно.

Дык это обычная практика в STL. Я всегда так делаю...