Можно ли реализовать связанные списки объектов разных типов?

[serbod]

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

Для небольших однопоточных программ в принципе пофиг. Это больше актуально для программ, работающих на пределе возможностей железа.

В стандартной библиотеке очень не хватает вариантов стандартных списков (TList и его потомки) основаных на связном списке и hash-таблице. То, что есть в fcl-stl (GVector, GSet) - либо тот же array, либо не совместимо с TList, под них нужно специально программу затачивать. Хотелось бы сделать возможность выбора "движка" списка при его создании.

[Devel0]

java73, посмотрите на реализацию в fcl-stl. В качестве типа T можно использовать Variant.

[zub]

>>На первый взгляд построить динамический связанный список, содержащий объекты разных типов, не получится. Так ли это?
не так. На чем основан такой первый взгляд?

>>Есть ли у нас аналог foreach еще?
есть и его можно прилепить к "динамический связанный список, содержащий объекты разных типов"

Devel0
зачем такие извращения? за Variant "просто потому что он есть" - надо по рукам лупить. а сунувшего Variant внутрь генерика - даже боюсь представить что ждет))

[vitaly_l]

зачем такие извращения? за Variant "просто потому что он есть" - надо по рукам лупить

Код: Выделить всё

Program Variantes;

uses variants;
type
   TEnumeratedData = (DataOne, DataTwo, DataTree);

var
   v : variant;
   s : ansistring;
   i : integer;
   r : real;
   c : TEnumeratedData;
   ss : string;

begin
   s:= Utf8ToAnsi(' Привет zub ;) ');
   v:= s;
   writeln(Utf8ToAnsi('Variant как AnsiString: '), v);

   i := 777;
   v:= i;
   writeln(Utf8ToAnsi('Variant как Integer: '), v);

   r:= 123.321;
   v:= r;
   writeln(Utf8ToAnsi('Variant как real: '), v);

   c := DataTwo;
   v := c;
   writeln(Utf8ToAnsi('Variant как Enumerated data: '), v);


   ss:= Utf8ToAnsi(' Привет zub ;) Не флуди... ;)  вот лучше почитай вику http://wiki.freepascal.org/Variant ');
   v:= ss;
   writeln(Utf8ToAnsi('Variant как String: '), v);

   readln;
end. 


[java73]

>>На первый взгляд построить динамический связанный список, содержащий объекты разных типов, не получится. Так ли это?
не так. На чем основан такой первый взгляд?

на отсутствии примеров обратного

>Есть ли у нас аналог foreach еще?
есть и его можно прилепить к "динамический связанный список, содержащий объекты разных типов"

ну напишите уже пример))

Добавлено спустя 6 минут 13 секунд:
Re: Можно ли реализовать связанные списки объектов разных типов?
Нашел вот русскоперевод документации по DecAL, там побольше структур создано, чем в fcl-stl.

[zub]

vitaly_l
Дуракам закон не писан. Даешь еще больше "хотькакованибудь" кода!. Ладно хоть научился компилируемые-запускаемые примеры давать. ито польза))

java73
Вечером если будет время ченибудь напишу.

>>Нашел вот русскоперевод документации по DecAL, там побольше структур создано, чем в fcl-stl.
ты тоже художник?

[vitaly_l]

java73
Вечером если будет время ченибудь напишу.

А как же стакан "седуксинчика" и спать?

[pupsik]

zub он безошибочнобезбагописательное существо...
По поводу темы. ТС бы почитать что то, а не пытаться хотелки из других поделий найти в фпс. Хотелки у каждого разные.

п.с.
vitaly_l, runewalsh: пасиб за познавательный описаний моего сообщения. Только вот зачем?

[zub]

vitaly_l
Ты всё путаешь, как всегда. Это я тебе этот рецепт выписывал.
java73

Код: Выделить всё

program Project1;

type
  TLinkedListElem=class;
  TLinkedListEnumerator = class
    fCurrent:TLinkedListElem;
    fFirst:TLinkedListElem;
  public
    constructor Create(FirstElem:TLinkedListElem);
    function GetCurrent:TLinkedListElem;
    function MoveNext:Boolean;
    property Current:TLinkedListElem read GetCurrent;
  end;

  TLinkedListElem=class
    Next:TLinkedListElem;
    function Add(Elem:TLinkedListElem):TLinkedListElem;
    procedure DoSomething;virtual;abstract;
    function GetEnumerator:TLinkedListEnumerator;
  end;
  generic GLinkedListElem<T>=class(TLinkedListElem)
    Data:T;
    constructor create(const _data:T);
    procedure DoSomething;override;
  end;
  TLinkedListIntegerElem=specialize GLinkedListElem<integer>;
  TLinkedListByteElem=specialize GLinkedListElem<byte>;
  TLinkedListStringElem=specialize GLinkedListElem<String>;
function TLinkedListElem.Add(Elem:TLinkedListElem):TLinkedListElem;
begin
  Next:=Elem;
  result:=Elem;
end;
function TLinkedListElem.GetEnumerator:TLinkedListEnumerator;
begin
  result:=TLinkedListEnumerator.Create(self);
end;
constructor TLinkedListEnumerator.Create(FirstElem:TLinkedListElem);
begin
  fCurrent:=nil;
  fFirst:=FirstElem;
end;
function TLinkedListEnumerator.GetCurrent:TLinkedListElem;
begin
  result:=fcurrent;
end;
function TLinkedListEnumerator.MoveNext:Boolean;
begin
  if fcurrent<>nil then
    fcurrent:=GetCurrent.Next
  else
    fcurrent:=ffirst;
  result:=fcurrent<>nil;
end;
constructor GLinkedListElem.create(const _data:T);
begin
  data:=_data;
end;
procedure GLinkedListElem.DoSomething;
begin
  writeln(data);
end;
var
  first,last,enumerated:TLinkedListElem;
begin
  first:=TLinkedListStringElem.create('first');
  last:=first.Add(TLinkedListStringElem.create('second'));
  last:=last.Add(TLinkedListIntegerElem.create(3));
  last:=last.Add(TLinkedListByteElem.create(4));

  for enumerated in first do
    enumerated.DoSomething;

  readln;
end.


На коленке и лень, поэтому - список односвязный и отдельного класса списка нет -цепочка из элементов, механизма очистки цепочки нет. Просто сам принцип ооп = общий предок+разные потомки в списке и прикручивание к этому делу for-in

Добавлено спустя 3 часа 18 минут 35 секунд:
Re: Можно ли реализовать связанные списки объектов разных типов?
vitaly_l

Код: Выделить всё

  ...   
  ...:= Utf8ToAnsi('...');
  writeln(Utf8ToAnsi('...'),...);
  ...
   writeln(Utf8ToAnsi('... '),..);
  ...
   writeln(Utf8ToAnsi('...'),...);
  ...
   writeln(Utf8ToAnsi('...'),...);
   ...:= Utf8ToAnsi('...');
   writeln(Utf8ToAnsi('...'),...);

Надо больше Utf8ToAnsi! Utf8ToAnsi слишком мало!

зы. как было хорошо раньше - вбил запрос в гугл и по первой-второй ссылке нашел что искал... Сейчас приходится пробираться через тонны "советов" таких вот "художников"...
Иди на какиенибудь маилруответы - там самое место таким как ты без комплексов советчикам и в каждый топик пописателям.

[vitaly_l]

Надо больше Utf8ToAnsi! Utf8ToAnsi слишком мало!

Вы что же знаете директиву для компилятора, которая заставит программу без Utf8ToAnsi работать в кирилицей в Windows CMD ?

На коленке и лень, поэтому - список односвязный и отдельного класса списка нет -цепочка из элементов, механизма очистки цепочки нет. Просто сам принцип ооп = общий предок+разные потомки в списке и прикручивание к этому делу for-in

Ну что за программист этот zub? Взял дженирики, приличный пример с которыми кстати ещё на первой странице сделал runewalsh, добавил к примеру итератор for-in, который кстати ещё на первой странице предложил alexs. И теперь козыряет дженириками с for-in, как мартышка из басен Крылова, а куда приладить результат zub, естественно не знает (в точности как герой басни Крылова). И поэтому zub уверяет что, "На коленке и лень, поэтому - список односвязный"... Но изначальной задачи, с ключами в виде строки, как в foreach, естественно zub так и не решил.

А вот такой простенький код, явно даёт возможности больше чем foreach в PHP (в сочетании с array).

Код: Выделить всё

type
PForeach = ^TForeach;
TForeach = record
key : variant;
value : variant;
end;


a ТС, судя по его задаче с HTML кодом, вообще достаточно и вот такого кода:

Код: Выделить всё

type
PForeach = ^TForeach;
TForeach = record
key : string;
value : string;
end;


И дженирики безусловно удобная фича, но в данной ситуации - вполне можно обойтись и без них, простым record из string и array. А если сделать класс с таким record, то можно зафигурить намного более удобную фишку чем foreach в PHP. Особенно, если туда добавить pointer, как предлагал изначально Лекс Айрин и в итоге добавить туда итератор как предложил alexs.

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

Zub - не комплексуй так сильно, подумаешь облажался посреди форума с определением координат мышки и проиграл на порядок по скорости какому-то художнику. Ну ведь такая ерунда с каждым бывает... чего ты так расстроился? ты главное к сердцу это не принимай! Ну облажался, ну проиграл по скорости на порядок. Ну с кем не бывает? Потом меня обучали довольно сильные программисты, и я уже чуть-чуть программист . Хорош уже комплексовать из-за такой фигни А?

[Лекс Айрин]

если сделать класс с таким record, то можно зафигурить намного более удобную фишку чем foreach в PHP. Особенно, если туда добавить pointer, как предлагал изначально Лекс Айрин .

record здесь нужен лишь как средство объединения переменных в одну. Если есть объект/класс то он излишен. И если есть базовый класс, то лучше pointer не использовать.

И дженирики безусловно удобная фича, но в данной ситуации - вполне можно обойтись и без них,

Можно... но кода придется писать намного больше. Я пробовал(( И когда решусь сделать свой список/дерево и пр.. то тоже буду использовать дженерики и классы. Хотя и не люблю их.

[vitaly_l]

Можно... но кода придется писать намного больше.

Ну куда больше-то??? Там обыкновенный array; Впрочем мне всё это пофиг. Пусть ТС учит дженерики - заодно появился ещё один рабочий пример с дженериками на форуме. Что только радует .

[Лекс Айрин]

Там обыкновенный array;

Это лишь контейнер. А вод код манипулирующий им просто жесть. Сплошные next^ и ^pred, а так же @data. Шаг вправо/влево и программа падает из-за неправильного обращения к памяти.
И, кстати, использование массива как основу списка я бы не назвал слишком правильной заменой. А уж если речь пойдет о деревьях и прочих сложных графах, то засада усложняется в разы.

[vitaly_l]

графах

О графах речи не шло. Разговор про foreach, в котором кстати ключи могут быть string, а не только цифры. В дженериках, насколько я вижу - эту задачу не решили. В дженериках возвращается только value в виде data, а про ключи забыли. Так что, вы оба: слышите звон, но не знаете где он.

[java73]

a ТС, судя по его задаче с HTML кодом

Та задача только 1/100 часть всего проекта), я просто расширяю его. А дженерики стал читать сначала в теоретических целях, но, почитав еще и руководство по deCAL, все больше вижу практических применений им, и в своем проекте в т.ч., но переписывать лень, я и так уже сделал усилие, переписав его под ООП.