· Начало · Отвђтить · Статистика · Поиск · FAQ · Правила · Установки · Язык · Выход · WASM.RU · Noir.Ru ·

 WASM Phorum —› WASM.WIN32 —› Сериализация объектов...

Посл.отвђт Сообщенiе


Дата: Июл 27, 2004 10:49:49

Назрел вот такой вот вопрос... предположим я создаю объекты каждому объекту даю свой уникальный идентификатор ... то бишь первый объект предположим имеет 1 .. второй 2 и тд... так вот удалю я скажим объект 2 ... или если у меня их несколько тысяч.. какой нибудь 4353646 ... так вот... при создании нового объекта как бы мне быстро занимать "свободные" сериалы под новый объект... (объектов может быть и миллион...)

п.с: сериал у объекта неизменяем!

есть идеи? алгоритмы?


Дата: Июл 27, 2004 14:35:15

Если только создать таблицу удаленных номеров и по ней ориетироваться


Дата: Июл 27, 2004 15:12:44

Если я правильно понял, то создай массив dword'ов а у объекта установи в GWL_USERDATA указатель на конкретный адрес в массиве, по которому прописан твой сериал. Уничтожаешь объект - обнули [GWL_USERDATA].Запомни адрес по которому сидит ноль чтобы при создании следующего не искать долго, какой у тебя ноль. Если сериалы идут по порядку, то находишь ноль, смотришь предыдущий делаешь ему inc и получаешь тот который был до стирания и присваиваешь новому объекту


Дата: Июл 27, 2004 15:44:36

Да насчет таблицы удаленных номеров это неплохая.. идея..

2cresta - это я не понял... GWL_USERDATA юзер дата...тут зачем? и тд и тп ...

в моём случае обект эта просто выделенная область памяти... в этой области и хранится его сериал и остальные значения...

так вот... необязательно если удалю объект то сразу создам новый.. я могу ещё 20 удалить ... а потом создать 7... неважно.. самое главное это возможность правильной сериализации вновь созданных объектов... причём после того как я например закрою программу список сериалов сохранятся и при запуске программы создаются объекты с этими сериалами....

п.с: может действительно создовать просто список удалённых... объектов и когда он исчерпает создовать объект с сериалом который будет ... (самый большой сериал + 1)


Дата: Июл 27, 2004 16:03:20

Fallout
у меня была недавно така проблема - писал диплом по распределенным вычислениям - там задача может "удалиться" (сеть отвалилась и т.п.).
я делал так:
1. имеем список идентификаторов, подлежащих обработке. Каждый элемент списка представляет собой рекорд из двух полей - начальый ИД, конечный ИД (sid,eid). Изначально в списке один рекорд (0,dword(-1)).
2. при выделении нового ИД берем sid первого рекорда. если для первого рекорда sid=eid, то такой рекорд просто удаляем, иначе делаем (sid+1,eid).
3. при возвращении ИД в список ищем, не примыкает ли удаляемый ИД вплотную к уже имеющемуся интервалу (ИД=sid-1 или ИД=eid+1). Если примыкает, то просто корректируем значения уже имеющегося рекорда, если нет - создаем новый рекорд со значениями (ИД,ИД) и добавляем его в список.

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


Дата: Июл 27, 2004 16:39:32

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


Дата: Июл 27, 2004 16:44:33

Поправлюсь - нет фрагментации памяти, а начле списка поставить общую длину :)


Дата: Июл 28, 2004 09:52:22

2Max - спасибо за идеи конечно .. но всё таки у меня может быть и миллион объектов ... и удалятся и создоваться должны моментально... просто если я даже построю дерево для быстрого поиска и даже если буду использовать метод быстрого поиска половинным дилением то всё ровно это не очень выход...

2ChS - да условий никаких нет занимать мне надо ЛЮБОЙ свободный.. и твоя идея как раз то что надо... быстро(что очень важно) и просто...


Powered by miniBB 1.6 © 2001-2002
Время загрузки страницы (сек.): 0.083