Ошибка "ambiguous call to overloaded function" для виртуальных функций - почему ? - страница 4

[Renat Fatkhullin]

TheXpert:

Таки хотелось бы услышать ваше мнение о моих постах о библиотеке и костыле выше. Интересно.

Я специально попросил конкретно сформулировать мнение. То, что было высказано - это лишь тень на плетень.

Начните с базового класса и укажите на ошибки или костыли:

class CObject
  {
private:
   CObject          *m_prev;               // previous item of list
   CObject          *m_next;               // next item of list

public:
                     CObject(void);
                    ~CObject(void);
   //--- methods to access protected data
   CObject          *Prev(void)                              const { return(m_prev); }
   void              Prev(CObject *node)                           { m_prev=node;    }
   CObject          *Next(void)                              const { return(m_next); }
   void              Next(CObject *node)                           { m_next=node;    }
   //--- methods for working with files
   virtual bool      Save(const int file_handle)                   { return(true);   }
   virtual bool      Load(const int file_handle)                   { return(true);   }
   //--- method of identifying the object
   virtual int       Type(void)                              const { return(0);      }
   //--- method of comparing the objects
   virtual int       Compare(const CObject *node,int mode=0) const { return(0);      }
  };

[TheXpert]

Renat:

То, что было высказано - это лишь тень на плетень.

Что и следовало ожидать :) все как обычно. Я все конкретно сформулировал.

[---]

TheXpert:

ну а если будет так

class CObject
  {
   CObject          *m_child[];

это хуже или лучше?

[Renat Fatkhullin]

TheXpert:
Что и следовало ожидать :) все как обычно. Я все конкретно сформулировал.

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

Или Вы считаете себя настолько профессионалом, что Ваши косвенные заявления не требуют доказательств?

[TheXpert]

sergeev:
это хуже или лучше?

Это ваще пипец :)

_______

Вот так примерно должен выглядеть базовый класс :)

class CObject
{
   virtual string Type() const {Assert(false); return "CObject";} // тупой ассерт, т.к. нету ни интерфейсов ни чисто виртуальных функций, а сюда мы попасть не должны ни при каком раскладе. Ассерта тоже нету )
};

Костыль со списком нафек.

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

А по хорошему базовый класс тоже нафек )))

[---]

TheXpert:

Это ваще пипец :)

_______

Вот так примерно должен выглядеть базовый класс :)

Костыль со списком нафек.

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

А по хорошему базовый класс тоже нафек )))

Андрей, погоди. Не суетись.

Давай разберемся с таким моментом.

Програмеру необходимо сделать массив объектов.  Пусть эти объекты имеют одного предка.

Например чтоб далеко не ходить имеем базовый класс CShape.  У него есть потомки - CRect, CTriangle. Есть и потомки от потомков.

И вот прогеру надо сделать массив этих объектов.  Что ты предлагаешь в этом случае?  Неужели массив CShape *[] или список это зло по всем проявлениям? 

И неужели базовый класс CShape это тоже зло?

// боюсь развивать твои высказывания дальше, а то щас окажется что наследование и полиморфизм тоже зло :)

[TheXpert]

sergeev:

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

Есть сущность объекта, есть сущность массива. Зачем сущности объекта знать что программисту нужен массив если самому объекту этот массив нафиг не нужен?

[---]

TheXpert:

Есть сущность объекта, есть сущность массива. Зачем сущности объекта знать что программисту нужен массив если самому объекту этот массив нафиг не нужен?

Но тут с какой точки зрения посмотреть.

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

Но во многих задачах это единственный удобный и практичный выход. Оcобенно, что касается интерфейсных наследований как в примере с CShape.

[Renat Fatkhullin]

TheXpert:

Это ваще пипец :)

_______

Вот так примерно должен выглядеть базовый класс :)

Костыль со списком нафек.

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

А по хорошему базовый класс тоже нафек )))

Ну понятно.

Теоретик-архитектор-фабрикостроитель в чистом виде. У нас хватает ума не создавать монстров на ровном месте.

Единственно верное замечание - это возможный ассерт в незаимплементированном Compare(). А в Type() ассерт не нужен, так как CObject является полноценным объектом со своим типом.

Ссылки Prev/Next ни в коем случае не являются костылем, а предоставляют базовую работу любого порожденного объекта в разнообразных коллекциях и списках. Это один из самых востребованных функционалов для работы с объектами.

Классы CList и CTree с помощью базовой поддержки CObject позволяют просто, эффективно и быстро работать со списками и деревьями.

[Renat Fatkhullin]

TheXpert:

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

Не путайтесь только.

Для любого объекта в рамках стандартной библиотеки (только в рамках дерева CObject). Никто не заставляет Вас обязательно порождаться из CObject.

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