OberonCore

Вот, в процессе портирования алгоритмов с С++, написал контейнеры для А2
http://sage.com.ua/ru.shtml?e1l5

Прикольно, но непонятно почему нельзя было создать классический контейнерный список, унаследованный от базового, а помещать базовый список внутрь как поле. И ещё один момент, как мне кажется ключевой. Если всё равно оборачивать базовые типы в запись, то почему нельзя было сразу сделать интерфейсную запись для списка ?

Что-бы избавиться от приведений типов при работе со списком, так как при наследовании в Оберонах нельзя нормально перекрыть методы предка (создать у потомка метод с тем-же именем, но другими типами параметров, например), можно только создать методы с другими именами. В итоге при наследовании получается венигрет из методов предка и новых методов, что не очень хорошо. Мы в этом случае лишаемся помощи компилятора в контроле типов, если случайно в коде используем не тот метод...
В смысле, делать внутренний массив типа этой записи? Конечно, тоже такое желание возникает, сэкономить память.
А с другой стороны... Допустим, есть у нас какие-то данные, представленные указателем на запись с десятком полей, и 2-3 структуры хранящие указатели на эти записи. Это надо, если есть необходимость отсортировать данные по разным полям, например. Фактически в этом случае имеем экономию памяти за счёт оперирования общими указателями между разными структурами.
Вот, бувально вчера реализацию алгоритма А* писал. Всё свелось к двум структурам: двоичной куче, построенной по одному полю и карте, отсортированной двум другим полям. В некоторых случаях, имея общий указатель, можно даже избежать вставки/удаления элементов!

Если нужно, то массив можно сделать и для ANY.

Говоришь, что хотел обойтись без приведения типов, но у тебя в примере получается приведение ANY к нужному типу.
Я имел ввиду базовый тип

А дальше либо от него наследоваться

либо проксировать

Ну и делать абстрактный List, а от него две реализации: LinkedList (через связный список) и ArrayList (через массив). Вечером попробую сделать свою реализацию и тогда выложу.

Правильно, приведение никуда не делось, оно просто спрятанно от пользователя данного класса, в реализации
Избавился от этого:

Выкладываю как и обещал. Правда там не полный исходный код, но базовые типы коллекций приведены полностью. За рамками остался Set и Map. Просто нету сейчас времени на них, ничего сложного, но много рутинной возни. Потом сделаю. В конце - примеры применения. Это не критика, просто многообразие вариантов. Чем больше - тем лучше.

Согласен, чем больше тем лучше конечно
Посмотрел, но мне кажется это немножко не то. Мне не нужен список, что-бы помещать в него числа и кнопки одновременно
А как в таком случае будет работать сортировка? Списку для этого нужно иметь представление о внутренней структуре элементов. Последовательный поиск элемента в списке это всё-таки очень медленно.
Какой возни?

Возни с набором кода и его проверкой.

По поводу сортировки добавляем:


Добавляем метод в Set


И делаем в методе Add проверку


Дальше по желанию. Можно сделать реализацию списка на основе чёрно-красных деревьев. Перегружать стандартные методы ещё никто не запрещал.

Сейчас исследую проблему "герметизации" списка через метаинформацию. Т.е. если получили первым элементом Button, то дальше можно добавлять только этот тип или его потомков.

Я при создании указываю тип объектов или NIL, если список разнородный. В таком случае можно сразу в комментариях писать тип элементов:

A: TList (* OF TButton *);

Одно дело коментарии и самому следить, другое дело когда будет вываливатся по ASSERTу.
В последнем случае мы гарантированно страхуемся от случайной ошибки при наборе кода.

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

Приведу пример для делфи:

Ассоциативный массив, где значения - списки.

Копание привело к одному интересному проекту - персистентный оберон. По предварительному взгляду возможно расширится до темплейтов типа

Тем временем, удалось таки для AO написать полностью всеядный базовый объект Vector для реализации на базе него всевозможных контейнеров. Причём, любые данные достаточно обернуть в статическую запись. Т.е. не требуется никаких дополнительных указателей. Единственный указатель во всём контейнере - динамический массив.
Удалось это не без помощи импорта модуля SYSTEM. Но для базового объекта это, пожалуй, простительно.
Бенчмарк RegExp показал, что с новыми контейнерами он работает почти в 2 раза быстрее чем с использованием старого Containers.Mod