Практические задачи

[klizardin]

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

И так задача.

Допустим реализованно некоторое сохранение данных на диск. Данные это некоторые структуры, и указатели на эти структуры. Но данные имеют желание когда нибуть удаляться, нужно сообщать о валидности или не валидности указателя на данные. Нужент класс или другая реализация указателя на данные. Допустим как то реализованна сериализация данных. Надо сохранять указатели на данные, дополнительные накладки, то что данные при загрузке могут не загрузиться т.е. и здесь возникает проблема с валидностью указателей. Да а сами указатели могут работать в многопоточной обстановке, так что очень полезно получив указатель залочить его и потом чтобы он автоматически разлочился. (кто то будет возражать против автоматического способа разлочивания, но есть стили написания работующего кода, при взаимодействии с которым программист может ошибаться и эти ошибки прощаются, да и зачем есть конструкторы и деструкторы)
И так нужны класс указателя (если C++ + templates, так уже сделано, но может есть и другие варианты) который знает что такое валидность. Также его нужно научить сохраняться и подумать какой подход при загрузке сохранении наилучший с точки зрения, сразу загрузить валидный указатель либо отложить иниуциализацию указателя до первого обращения. И нужно же реализовать мультипоточную поддержку для указателей на данные.

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

 

[Dr.Gigabit]

И так нужны класс указателя (если C++ + templates, так уже сделано, но может есть и другие варианты) который знает что такое валидность.

Что-то туговато соображаю, но что значит валидность.

template<class T> class CSmartPrt
{
T* m_pSmart;

public:
CSmartPtr(T* pData)
{
 assert(pData != NULL);
 m_pStart = pData;
}
.........
}

Далле используем лист таких указателей. Т.е лист будет содержать несколько по определению валидных указателей.
Т.е мы приходим к имплементации auto_prt, возможно с некоторыми модификации.

p.s.Не касаясь пока вопроса многопоточности....

 

[Guest]

Нет, парень вроде говорит о том что есть в обертке есть указатель на объект, а в другом месте объект удаляют. Обертка должна об этом узнать. Что, имхо, является признаком серьезных проблем с организацией программы в целом.

 

[klizardin]

Что-то туговато соображаю, но что значит валидность.

Нет, парень вроде говорит о том что есть в обертке есть указатель на объект, а в другом месте объект удаляют

-- действительно так. И обертка знает о том что указатель удалился и обертка же поддерживает локирование обьекта.
С точки зрения задания.
В моем варианте, далее она знает как связаться с хранилищем и отыскать обьект. Ну а сам оригинально обьект знает
о списке указателей на него и когда удаляется то выставляет невалидность этих указателей. Ну и хранилище как
подтип обьекта знает список указателей которые еще не загруженны. Тогда соответственно при обращении к обьекту
обертка смотрит валидна ли она и если да запрашивает адресс у обьекта, если нет, то банально возращает NULL.

Что, имхо, является признаком серьезных проблем с организацией программы в целом

Это уже ближе, к делу.
А как тогда можно организовать списки данных с ссылками друг на друга ?
Или какая другая структура данных позволяет обойти данные неприятности ?
С одной то стороны нужно экономить память да и целостность данных соблюдать.
(не пользуясь лишним копированием)
Хорошо в NET-е у них с сериализацией чуть по лучше чем в VC.
В "школе" учат использованию указателей, чуть позже узнаешь про STL и дальше пользуешся iterator-ами, но и они
в чистом виде не спасают в данной ситуации.

Если есть предложение о том что же в корне самой задачи не верно, с благодарностью выслушаю.

 

[Guest]

Чтобы дать совет надо знать больше о задаче. Списки данных со ссылками друг на друга? Ну и что, где здесь необходимость держать список ссылок? Вопрос в том, какие операции и как должны выполняться над данными. Пока же, по тому что ты описал, можно только посоветовать классический подсчет ссылок. Создаешь объект А, счетчик = 1, если надо держать на него еще один указатель - счетчик++, вместо удаления - А->Release(), который :
void MyObject::Release()
{
m_nRefCounter--;
if (m_nRefCounter<=0)
delete this;
}

Тогда объект будет существовать пока на него есть ссылки. Почитай книжку по COM (того же Роджерсона), там механизм описан.
Заметь - в этой схеме об'ект существует всегда, и нет ситуации когда кто-то удаляет данные, которые еще кому-то нужны. У тебя зачем указатель на данные лежит, если они могут быть удалены в любой момент? Может, тебе надо просто флаг "не валиден" завести для об'екта? Тогда кто-то сможет сказать об'екту - ты больше не валиден, и пользователь перед использованием сможет этот флаг проверить. Установку\опрос флага можно сделать синхронизированным - тогда и твои многопоточные проблемы решатся.

 

[klizardin]

Чтобы дать совет надо знать больше о задаче. Списки данных со ссылками друг на друга? Ну и что, где здесь необходимость держать список ссылок? Вопрос в том, какие операции и как должны выполняться над данными. Пока же, по тому что ты описал, можно только посоветовать классический подсчет ссылок.

В принципе задача разарасталась от желания сделать сохранение обьектов. Здесь и нужна валидность обьектов. Далее
из-за того что возможна ситуация когда обьект теряется в носителях данных, отсюда возникла ситуация с валидными
указателями.

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

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

 

[ZarathustrA]

а почему бы обертку не снабдить флагом валидности указателя и средствами манипулирования этим флагом, а объект указателем на обертку. В конструкторе объекта поднимать флаг, а в деструкторе опускать.
Или такой вариант не прокатит?

В принципе класс обертку можно превратить в класс-диспетчер, который будет контролировать валидность указателей. Все создаваемые объекты прописываются в объекте-диспетчере, все удаляемые - выписываются. Прописку/выписку обеспечить на базе конструктора/деструктора.

 

[European]

Для: ZarathustrA
На дату последнего сообщения посмотри