Ошибка "ambiguous call to overloaded function" для виртуальных функций - почему ? - страница 3
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Чеку вырвал, гранату бросил :) ну держись :)
Ты мне? :) Так я еще могу вбросить :)
Имхо, первое, что должны были реализовать в стд библиотеке, это легко встраиваемый трейсинг и утверждения(assertions). Еще можно было бы оболочку вокруг OutputDebugString.
А реализация объекта CObject в виде ноды листа -- это вообще костыльнейший костыль. Там вообще много интересного для обсуждения, просто ворошить не хочется, забанят стопудофф.
TheXpert:
А реализация объекта CObject в виде ноды листа -- это вообще костыльнейший костыль.
про костыль возможно, но почему костыльнейший? какое неудобство в такой структуре?
Эмм зачем такая организация для самого базового класса? Для подпорки ошибки в архитектуре на более высоком уровне, больше незачем. Ответ "шоб було" не канает ни при каком раскладе.
Навскидку -- этот объект предполагает его использование в качестве базового для любого объекта. Поэтому для простых объектов за счет того, что есть два описателя, может конкретно замедлиться работа с ними (объектами) в массиве.
________________
Вообще дурная тема конечно. Я просто стд. библиотеку стараюсь не трогать никаким боком. На этом тему пожалуй закончим :)
Вы как-то конкретнее объясняйтесь, пожалуйста.
Нам тоже интересно узнать про костыли.
А я согласен, что в базовом классе объекта не должно быть функциональности списка.
Но, MQL5 по сравнению с MQL4 - огромный прорыв. И стандартная библиотека - на то и стандартная, чтобы ее не трогать, а если что кому надо - то все реализуется в наследуемых классах.
С дебаг-релиз модификациями я извернулся, отладочные assert-ы тоже себе сделал, но вот чего мне жутко не хватает - это отладки в тестере стратегий. Хорошо еще, что на реальных тиках отладка работает, и за то уже спасибо. А то приходится ориентироваться на трассировочные сообщения, а такая отладка - крайне муторна и неэффективна.
Вы как-то конкретнее объясняйтесь, пожалуйста.
Нам тоже интересно узнать про костыли.
Ренат, выдайте ему, пожалуйста, индульгенцию (от бана) на неделю вперёд, пусть скажет всё как есть, по честному.
// Потом можно и киллера заслать, ежли лишнего сболтнёт... )))
Эмм зачем такая организация для самого базового класса? Для подпорки ошибки в архитектуре на более высоком уровне, больше незачем. Ответ "шоб було" не канает ни при каком раскладе.
Навскидку -- этот объект предполагает его использование в качестве базового для любого объекта. Поэтому для простых объектов за счет того, что есть два описателя, может конкретно замедлиться работа с ними (объектами) в массиве.
Андрей, ну давай все же определимся в хорошей и плохой технологии.
Мне интересно из практических соображений, чтоб в будущем не проектировать плохие иерархии. Поэтому поясни пожалуйста до конца.
CObject базовый. Тут я думаю не возникает претензий к такому раскладу. Один родитель, чтоб пользоваться функционалом Type() в любом потомке.
Вопрос в наличии указателей на соседа. Причем ты заметь, что это не структура дерева у него получается, а просто линия с двумя соседями по бокам.
но наверно вопрос даже не в количестве соседей. а в практичности их наличия в базовом классе.
Ты считаешь, что это плохо. Но на практике разве не используются постоянно именно массивы объектов?
Нам тоже интересно узнать про костыли.
Ренат, я уже настолько привык к равнодушию с вашей стороны на предложения и замечания, что желание делиться пропало, так что просто выражаю мнение. Пока можно конечно )
Просто у меня такое подозрение, что тот, кто предложил назвать вашу библиотеку стандартной понятия не имеет что это такое.
Я все.
__________
Хотя нет. Таки хотелось бы услышать ваше мнение о моих постах о библиотеке и костыле выше. Интересно.
но наверно вопрос даже не в количестве соседей. а в практичности их наличия в базовом классе.
Ты считаешь, что это плохо. Но на практике разве не используются постоянно именно массивы объектов?