Парадигмы ООП

[Tuborg]

Как это изобразить через ООП?

Есть некий диалог, на котором пользователю предлагается выбрать источник принимаемых данных (Файл, UDP, LPT, UART). При выборе пользователь заполняет параметры источника (порт, аддрес, имя файла и прочее). По завершению диалога надо вернуть в родительскую функцию (откуда происходил вызов диалога) информацию о выбранном источнике данных. Если пользователь выбрал UDP, то возвращается объект класса UDPStreamSrc, если пользователь выбрал Файл, то диалог возвращает объект класса FileSrcInfo;

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

Теперь к основной проблеме - что возвращать функции EndDialog (по завершении работы диалога)? Указатель на объект базового класса? И на принимающей стороне уже решать что там конкретно вернулось - толи UDPStreamSrc, толи FileStreamSrc (например в базовом классе есть поле Type, которое в каждом ребёнке-классе имеет своё значение).

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

 

[Антон (LogRus)]

я бы возвращал указатель на интерфейс и положил бы его в какой нибуть умный указатель, что бы не забыть прибить его как будет не нужен
Что касает деструктора, так на, то он и виртуальный, что бы удаляться как надо

[Джон]

Можно передавать в диалог указатель на указатель типа базового класса.

Грубый эскиз:

class CSrcTypeBase
class FileSrcInfo : public CSrcTypeBase
class UDPStreamSrc: public CSrcTypeBase

в месте вызова

CSrcTypeBase *pSrc = NULL;

CMyDlg dlg;
if(dlg.DoModal(&pSrc)==IDOK) // DoModal надо будет переписать или сделать другую какую ф-ю
{

    ... делаем что надо с данными
      и очищаем память.

     delete pSrc;
}


Создание объекта в диалоге:

*pSrc = new FileSrcInfo();

или

*pSrc = new UDPStreamSrc();

[Tuborg]

А расскажите про умные указатели... я много что читал... но так не разу и не воспользовался ими...

[Джон]

Хм, а что рассказывать, если ты много читал? Лучше спроси, что непонятно, или почему не пользовался?

[Антон (LogRus)]

Можно передавать в диалог указатель на указатель типа базового класса.

Я бы тогда передовал бы умный указатель, scoped_ptr или shared_ptr внутри заполнил, а потом полузуешься.

А расскажите про умные указатели... я много что читал... но так не разу и не воспользовался ими...

А чего тут расказывать, просто способ гарантированно удалить выделеный через new объект, не надо парится с позможными исключения которые могут вызватся до того, как ты явно сделаешь delete

обычно умными указателями пожно пользоваться, как обычными использовать во всяких там if т.к. у них есть приведение к bool

std::auto_ptr не очень люблю какие-то у него есть проблемы с передачей в функции
boost::scoped_ptr и boost::shared_ptr самые популярные в моей работе
scoped_ptr практически такой же как auto_ptr прибевает хранимый объект, в деструкторе или по запросу
shared_ptr прибевает объект, только когда хранимый объект больше не используется в других shared_ptr или по запросу

умный указатель можно попросить отдать владение хранимым обектом через метод release
например, после того как ты передал управление временем жизни объекта своему контейнеру

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

[Tuborg]

Джон, просто вопрос инструментов.... вот я решил вы$#ернуться через ООП, наследование и базовые классы в моём случае с диалогом, хотя всегда до этого пользовался union'ами... там всегда гарантированно знаешь сколько памяти взял и что с ней с делал.... как-то я C больше уважаю чем С++ =))) А про умные указатели не понимаю почему простыми проще не воспользоваться, ведь как пишет LogRus, в std::auto_ptr есть проблемы... вобще пытаюсь обходить стороной навороты, которые не видно как реализованы внутри.... дебажить чужие баги - не есть моё хобби =)))

[Алексей++]

Tuborg,
>>пользовался union'ами... там всегда гарантированно знаешь сколько
>> памяти взял и что с ней с делал.

пользуйся классами и структурами лучше )

но тем не менее, не всегда знаешь заранее, сколько памяти потребуется, а лишнее выделять заранее и навсегда (статически то есть) - совесть не позволяет (мне) )))

-------
умные указатели, кстати, тоже не понимаю, никогда с ними проблем не было. В крайнем случае, если много заморочек с проверками, то делаю структурку с инкапсулированным созданием нужного объекта через new и удаление в деструкторе. В эту же структурку сую ин\струменты для работы с объектом.

[Джон]

Ну значит так - в принципе с технической точки зрения в использовании умных указателей и нормальных нет никакой разницы. Умные указатели дают тебе возможнось не заботиться об освобождении памяти. Такое бывает просто жизненно необходимо когда работаешь с одной инстанцей объекта сразу в нескольких местах (передаёшь в них указатель на него) или другими словами сразу несколько объектов хранять указатель на эту инстанцию. В таком случае если вдруг происходит уничтожение объекта (например неправильный порядок удаления объектов), то получается куча объектов с указателями на уже удалённый объект. Последствия ясны.
Умный указатель хранит счётчик таких копий и удаление умного указателя в каждом из объектов приводит к уменьшению счётчика. Когда счётчик равен нулю происходит удаление хранимого объекта.

Вроде бы уже было на форуме обсуждение про них. Поищи.
В плане хорошо это или плохо... ИМХО вопрос дисциплины. УУ расхолаживают программера, те если "чисто" работать с нормальными указателями, то всё будет в порядке. С другой стороны, их большим недостатком является недопустимость использования чистых указателей в мешанине с УУ. Как только ты где-то воспользовался напрямую простым указателем из обёртки УУ, то это так же пагубно как, удалить объект.
Ошибку в таком случае бывает гораздо труднее найти. Так что это тоже вопрос дисциплины.

Я лично пользуюсь УУ только в случае сложных списков и перекрёстных структур. Да и в этом случае я делаю свои УУ.

А с ООП тебе всё-равно будет проще. Именно из-за базового класса. Иначе придётся создавать переменные разных типов. А если честно, то я даже представить не могу как такое можно просто (в смысле легко) без ООП сделать.

Предавать в диалог простой указатель или УУ зависит от сложности диалога. Если диалог использует другие структуры для обработки, в которые, например, передаёт этот указатель, то тогда лучше всего использовать УУ - сделай свой, штука-то немудрёная,  он хранит указатель на объект созданный по new и счётчик, в каждом copy-constructor этого объекта счётчик увеличивается, а в деструкторе уменьшается, когда счётчик равен нулю вызываешь delete для хранимого указателя. Вот и весь фокус. Во всех остальных местах ты пользуешься только объектами этого типа и создаёшь где надо копии.

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

[Антон (LogRus)]

В плане хорошо это или плохо... ИМХО вопрос дисциплины. УУ расхолаживают программера, те если "чисто" работать с нормальными указателями, то всё будет в порядке.

а как же исключения или ты всегда создание/удаление делаешь в одной функции и делаешь перехват по трём точкам? и потом удаляешь данные в порядке их создания? Зачем эта головная боль?
{
boost::scoped_ptr<ClassA> pA(new ClassA);
boost::scoped_ptr<ClassB> pB(new ClassB(pA));
}
Умный указатель тебе ГАРАНТИРУЕТ, что раскрутка стека приведёт к удалению созданных объектов
в данном случае выход из области видимости гарантирует, что выделеная память будет возвращена куче, а объекты будут удалены в правильном порядке.

Что касается написания смартпоитеров, так лично я не готов утвержать, что сделаю это не хуже, чем авторы STL/BOOST/LOKI
У нас были раньше самописные, но они все умерли слава богу.

[Алексей++]

а вот я в своих программах могу точно утверждать, что сделаю работу с указателями лучше, чем "авторы STL/BOOST/LOKI" (c)

[Джон]

LogRus, совершенно верно. Именно так и делаю. В каждом catch-блоке удаляю. Ну и что? Лично у меня голова от этого не болит. Просто я не так часто использую исключения. Вот и всё. А свои УУ делаю исключительно потому, что точно знаю ЧТО и КАК они делают.

Умный указатель тебе ГАРАНТИРУЕТ, что раскрутка стека приведёт к удалению созданных объектов

Это только в том случае если ты ВСЕГДА и ВЕЗДЕ используешь ТОЛЬКО обёртку УУ. Но стоит только хоть где-нибудь, когда-нибудь (это не обязательно должен быть ты, с проектом работают куча людей) напрямую воспользоваться указателем, уже эта гарантя неосуществима. А ошибку будет очень трудно найти.

Что касается написания смартпоинтеров, так лично я не готов утвержать, что сделаю это не хуже, чем авторы STL/BOOST/LOKI

Думаешь они какие-то особенные программеры и никогда не ошибаются?

[Антон (LogRus)]

Думаешь они какие-то особенные программеры и никогда не ошибаются?

Да

[Джон]

LogRus,

[Алексей++]

не ошибается тот, кто не пьёт шампанское!

[Dimka]

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

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

Не выйдет. Всё будет нормально.

А умные указатели здесь совершенно не в тему