OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 20 Февраль, 2019 12:04

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 13 ] 
Автор Сообщение
СообщениеДобавлено: Среда, 29 Февраль, 2012 14:45 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 975
Откуда: Украина, Киев
Вот, в процессе портирования алгоритмов с С++, написал контейнеры для А2 :)
http://sage.com.ua/ru.shtml?e1l5


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Март, 2012 21:20 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 572
Откуда: Россия, Санкт-Петербург
Прикольно, но непонятно почему нельзя было создать классический контейнерный список, унаследованный от базового, а помещать базовый список внутрь как поле. И ещё один момент, как мне кажется ключевой. Если всё равно оборачивать базовые типы в запись, то почему нельзя было сразу сделать интерфейсную запись для списка ?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Март, 2012 11:43 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Март, 2012 12:37 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 572
Откуда: Россия, Санкт-Петербург
Если нужно, то массив можно сделать и для ANY.

Говоришь, что хотел обойтись без приведения типов, но у тебя в примере получается приведение ANY к нужному типу.
Я имел ввиду базовый тип
Код:
ListItem = POINTER TO RECORD END;

А дальше либо от него наследоваться
Код:
MyType = POINTER TO RECORD(ListItem)
    ...
END;

либо проксировать
Код:
ProxyType = POINTER TO RECORD(ListItem)
    item : MyType;
END;

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Март, 2012 13:02 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 975
Откуда: Украина, Киев
Madzi писал(а):
Говоришь, что хотел обойтись без приведения типов, но у тебя в примере получается приведение ANY к нужному типу.
Правильно, приведение никуда не делось, оно просто спрятанно от пользователя данного класса, в реализации :D
Избавился от этого:
Цитата:
i := lstMyInts.GetItem(j)(LongintItem).value;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Март, 2012 21:07 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 572
Откуда: Россия, Санкт-Петербург
Выкладываю как и обещал. Правда там не полный исходный код, но базовые типы коллекций приведены полностью. За рамками остался Set и Map. Просто нету сейчас времени на них, ничего сложного, но много рутинной возни. Потом сделаю. В конце - примеры применения. Это не критика, просто многообразие вариантов. Чем больше - тем лучше.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Март, 2012 10:05 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 975
Откуда: Украина, Киев
Согласен, чем больше тем лучше конечно :)
Посмотрел, но мне кажется это немножко не то. Мне не нужен список, что-бы помещать в него числа и кнопки одновременно :D
А как в таком случае будет работать сортировка? Списку для этого нужно иметь представление о внутренней структуре элементов. Последовательный поиск элемента в списке это всё-таки очень медленно.
Цитата:
За рамками остался Set и Map... ничего сложного, но много рутинной возни.
Какой возни?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Март, 2012 11:38 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 572
Откуда: Россия, Санкт-Петербург
Цитата:
Какой возни?

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

По поводу сортировки добавляем:
Код:
(**
 * @return 1 : Item1 > Item2
 *             0 : Item1 = Item2
 *            -1 : Item1 < Item2
 *)
Comparator = PROCEDURE {DELEGATE} (Item1, Item2 : ListItem) : LONGINT;


Добавляем метод в Set
Код:
PROCEDURE SetComparator(comparator : Comparator);


И делаем в методе Add проверку
Код:
PROCEDURE Add*(item : ListItem);
BEGIN
    ASSERT(comparator # NIL);
    ...
END Add;


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Март, 2012 14:52 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Цитата:
Сейчас исследую проблему "герметизации" списка через метаинформацию.

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

A: TList (* OF TButton *);


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Март, 2012 14:59 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 572
Откуда: Россия, Санкт-Петербург
Одно дело коментарии и самому следить, другое дело когда будет вываливатся по ASSERTу.
В последнем случае мы гарантированно страхуемся от случайной ошибки при наборе кода.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Март, 2012 19:20 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
По ASSERT-у и есть. Просто тип указывается при создании контейнера явно (а не при добавлении первого элемента), а в комментариях фиксируется для читающего.

Приведу пример для делфи:
Код:
Events: AssocArrays.TAssocArray {OF Lists.TList};
...
Events  :=  AssocArrays.NewStrictAssocArr(Lists.TList);

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Март, 2012 23:25 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 572
Откуда: Россия, Санкт-Петербург
Копание привело к одному интересному проекту - персистентный оберон. По предварительному взгляду возможно расширится до темплейтов типа
Код:
VAR
    list : List {LONGINT};


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 30 Май, 2016 21:59 
Аватара пользователя

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


Вложения:
Vector.zip [3.77 КБ]
Скачиваний: 117
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 13 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB