Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Парадигмы ООП  (Прочитано 16258 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Tuborg
Команда клуба

ee
Offline Offline

« : 24-09-2007 13:55 » 

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

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

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

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

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

 Здесь была моя ладья... Не понял А черт его знает...
Записан
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #1 : 24-09-2007 14:01 » 

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

Странно всё это....
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #2 : 24-09-2007 14:28 » 

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

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

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();

Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Tuborg
Команда клуба

ee
Offline Offline

« Ответ #3 : 24-09-2007 14:46 » 

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

de
Offline Offline
Пол: Мужской

« Ответ #4 : 24-09-2007 21:09 » 

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

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #5 : 25-09-2007 05:19 » 

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

Я бы тогда передовал бы умный указатель, 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
Команда клуба

ee
Offline Offline

« Ответ #6 : 25-09-2007 08:25 » 

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

ru
Offline Offline
Сообщений: 13


« Ответ #7 : 25-09-2007 08:38 » 

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

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

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

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

Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #8 : 25-09-2007 09:08 » 

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

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

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

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

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

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

Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #9 : 26-09-2007 06:15 » 

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

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

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

Странно всё это....
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #10 : 26-09-2007 06:35 » 

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

Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #11 : 26-09-2007 09:18 » 

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

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

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

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

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

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Антон (LogRus)
Глобальный модератор

ru
Offline Offline
Пол: Мужской
Внимание! Люблю сахар в кубиках!


WWW
« Ответ #12 : 27-09-2007 04:56 » new

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

Да Улыбаюсь

Записан

Странно всё это....
Джон
просто
Администратор

de
Offline Offline
Пол: Мужской

« Ответ #13 : 27-09-2007 08:21 » 

LogRus, Улыбаюсь
Записан

Я вам что? Дурак? По выходным и праздникам на работе работать. По выходным и праздникам я работаю дома.
"Just because the language allows you to do something does not mean that it’s the correct thing to do." Trey Nash
"Physics is like sex: sure, it may give some practical results, but that's not why we do it." Richard P. Feynman
"All science is either physics or stamp collecting." Ernest Rutherford
"Wer will, findet Wege, wer nicht will, findet Gründe."
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #14 : 27-09-2007 08:23 » 

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

Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #15 : 27-09-2007 14:01 » 

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

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

А умные указатели здесь совершенно не в тему Улыбаюсь
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines