Ошибка "ambiguous call to overloaded function" для виртуальных функций - почему ? - страница 4
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Таки хотелось бы услышать ваше мнение о моих постах о библиотеке и костыле выше. Интересно.
Я специально попросил конкретно сформулировать мнение. То, что было высказано - это лишь тень на плетень.
Начните с базового класса и укажите на ошибки или костыли:
То, что было высказано - это лишь тень на плетень.
ну а если будет так
class CObject { CObject *m_child[];
это хуже или лучше?Что и следовало ожидать :) все как обычно. Я все конкретно сформулировал.
То есть, ничего конкретного после двух явных запросов "укажите конкретно на проблемы и подтвердите их корректность/значимость".
Или Вы считаете себя настолько профессионалом, что Ваши косвенные заявления не требуют доказательств?
это хуже или лучше?
Это ваще пипец :)
_______
Вот так примерно должен выглядеть базовый класс :)
Костыль со списком нафек.
Сериализация должна быть описана отдельным интерфейсом или базовым классом, так что тоже нафек. Но за неимением множественного наследования и эту хрень впихнули в базу )
А по хорошему базовый класс тоже нафек )))
Это ваще пипец :)
_______
Вот так примерно должен выглядеть базовый класс :)
Костыль со списком нафек.
Сериализация должна быть описана отдельным интерфейсом или базовым классом, так что тоже нафек. Но за неимением множественного наследования и эту хрень впихнули в базу )
А по хорошему базовый класс тоже нафек )))
Андрей, погоди. Не суетись.
Давай разберемся с таким моментом.
Програмеру необходимо сделать массив объектов. Пусть эти объекты имеют одного предка.
Например чтоб далеко не ходить имеем базовый класс CShape. У него есть потомки - CRect, CTriangle. Есть и потомки от потомков.
И вот прогеру надо сделать массив этих объектов. Что ты предлагаешь в этом случае? Неужели массив CShape *[] или список это зло по всем проявлениям?
И неужели базовый класс CShape это тоже зло?
// боюсь развивать твои высказывания дальше, а то щас окажется что наследование и полиморфизм тоже зло :)
И вот прогеру надо сделать массив этих объектов. Что ты предлагаешь в этом случае? Неужели массив или список это зло по всем проявлениям?
Есть сущность объекта, есть сущность массива. Зачем сущности объекта знать что программисту нужен массив если самому объекту этот массив нафиг не нужен?
Есть сущность объекта, есть сущность массива. Зачем сущности объекта знать что программисту нужен массив если самому объекту этот массив нафиг не нужен?
Но тут с какой точки зрения посмотреть.
Ведь организация иерархий может быть самая разная. В некоторых случаях массив или указатели на самого себя в базовом классе это ненужно.
Но во многих задачах это единственный удобный и практичный выход. Оcобенно, что касается интерфейсных наследований как в примере с CShape.
Это ваще пипец :)
_______
Вот так примерно должен выглядеть базовый класс :)
Костыль со списком нафек.
Сериализация должна быть описана отдельным интерфейсом или базовым классом, так что тоже нафек. Но за неимением множественного наследования и эту хрень впихнули в базу )
А по хорошему базовый класс тоже нафек )))
Ну понятно.
Теоретик-архитектор-фабрикостроитель в чистом виде. У нас хватает ума не создавать монстров на ровном месте.
Единственно верное замечание - это возможный ассерт в незаимплементированном Compare(). А в Type() ассерт не нужен, так как CObject является полноценным объектом со своим типом.
Ссылки Prev/Next ни в коем случае не являются костылем, а предоставляют базовую работу любого порожденного объекта в разнообразных коллекциях и списках. Это один из самых востребованных функционалов для работы с объектами.
Классы CList и CTree с помощью базовой поддержки CObject позволяют просто, эффективно и быстро работать со списками и деревьями.
Навскидку -- этот объект предполагает его использование в качестве базового для любого объекта.
Не путайтесь только.
Для любого объекта в рамках стандартной библиотеки (только в рамках дерева CObject). Никто не заставляет Вас обязательно порождаться из CObject.
Хотите эффективный процессинг без потерь - используйте сырые структуры или легкие классы без виртуальных методов и сложных связей. Но как только дойдете для связей список/дерево между объектами, сразу придете к аналогичной схеме как в CObject.