Правильна ли такая реализация списка из указателей на базовый класс?

[Archet]

Сообщение от counter

ну ну ну... погорячился...

Говорил я, что указатель нулевой? Почему отладчиком не прошелся?

if (temp==NULL){temp=new PList;
		temp->content=new PackMail; 
		temp->next=NULL;
		head=temp; // кто указатель на место вернет?
		}

Facepalm.jpg, бьюсь головой об стол. Проморгал.
Отладчик в Dev C++ не шибко удачный, понадеялся на свою голову.

По поводу приведения типов:
А если классов-наследников несколько, то как реализовать этот момент по-человечески в функции ServTable::showall()?
Просто, если я верно понимаю,

((PackMail*)temp->content)->set_d2(t1);

корректно работает только для класса PackMail.
Получается, нужно создавать функцию со switch(),например, для обработки различных классов-потомков?

[counter]

Сообщение от Archet

По поводу приведения типов:
А если классов-наследников несколько, то как реализовать этот момент по-человечески в функции ServTable::showall()?
Просто, если я верно понимаю,

((PackMail*)temp->content)->set_d2(t1);

корректно работает только для класса PackMail.
Получается, нужно создавать функцию со switch(),например, для обработки различных классов-потомков?

в showall у тебя все нормально, у каждого наследника есть свой show и поэтому проблем там не будет...

а вот AddPack придется переделать... каждому наследнику придется добавить свой input-метод для ввода данных

Сообщение от Archet

Facepalm.jpg, бьюсь головой об стол.

Осторожно! Стол...

[Archet]

А вот не совсем там все в порядке, как оказалось при тестировании.

Условие

temp->next!=NULL

в цикле для showall(); нужно было заменить на

temp!=NULL

а то последний элемент не выводил. Но это уже мелочи.

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

[_Bers]

Сообщение от Archet

Мини-проект сейчас сделаю.

А пока еще один вопрос:
_Bers, как в общих чертах должна выглядеть правильная реализация такого списка и вызов этого виртуального метода для содержащихся в нем объектов класса-потомка?

Изготавливаешь самый обыкновенный класс контейнера.
Если тебе нужен именно список - значит это будет контейнер, который будет хранить данные по принципу связанного списка.
(Лично я б поюзал STL)

При этом, забудь о полиморфизме. Контейнер ничего не знает ни о каких полиморфах. Единственное - он должен хранить указатель заданного типа.

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

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

Дизайн кода может выглядеть вот так:

CContainer myCont; //создали контейнер.

Метод добавления нового пассажира на хранение может выглядеть вот так:

myCont.Add( ptr_base& * target); //прототип метода, добавляющего в контейнер элемент, 
//созданный где то снаружи.

Тогда создание/добавление объекта может выглядеть так:

ptr_base* myConcreteObj = new Concrete(); //создали конкретный объект снаружи.

myCont.Add( myConcreteObj ); //передали право владения объектом контейнеру.
// С этого моменте контейнер сам контролирует время жизни объекта.

Внутри себя, при добавлении, оригинальный указатель можно занулить (тем самым снаружи больше никто уже ничего не будет знать о созданном объекте. Это гарантирует, что контейнер стал единственным владельцем объекта)

Итого, общий дизайн кода может выглядеть так:

CContainer myCont; //создали контейнер.
ptr_base* myConcreteObj = new Concrete(); //создали конкретный объект.
myCont.Add( myConcreteObj ); //передали право владения объектом 

//теперь myConcreteObj равно NULL, а только контейнер знает адрес объекта.

myConcreteObj = new Concrete1(); //создали другой конкретный объект.
myCont.Add( myConcreteObj ); //передали право владения этим объектом 

//теперь контейнер хранит внутри себя указатели на два разных объекта. 
//Но сам контейнер думает, что оперирует одним и тем же типом данных
//А именно: ptr_base*

Дальше, запускаешь метод контейнеру. В этом методе, запускается цикл, в котором по очереди вызываются все хранимые указатели, и по каждому указателю делается ptr -> Show();

Таким образом возникает контракт: каждый из полиморных объектов обязаны иметь метод Show()

Что до самого контейнера: то он ожидает, что объекты имеют метод Show(), хотя ничего не знает о природе своих подопечных

[Archet]

_Bers, спасибо за информацию к размышлению, буду разбираться.