Здравствуйте, Erop, Вы писали:

E>Здравствуйте, creatman, Вы писали:

C>>Поправка: не у Саттера а у Майерса (Наиболее эффективное использование C++). Там как раз раскрывается тема коллизии динамических объектов в компьютерных играх. На сколько мне не изменяет память, Александресску ссылался в своих мульти методах на Майерса и от себя добавлю, что А привел более удачное решение проблемы.

E>Типа для выбора обработчика столконовения?
E>Что будет, если пуля типа 8 попадает в монстра типа 13?

Ага для этого.

E>В принципе я соглачен, что там мультиметоды могут быть уместны.
E>Правда у меня в анологичной задаче (правда не из области игрушек ) было не совсем так.
E>Было так, что есть пара типовых реакций. И есть ещё штуки три нетиповых.
E>Соответсвенно хорошо получается с двойной диспечеризацией, что довольно похоже на мультиметоды, в принципе, но и с if'ами в таком раскладе всё выгляди т не особо плохо.

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

E>Скажем в моей задаче, если продолжать аналогию, большинство монстров реагирует на столкновене с пулей одинаково, есть один монстр, который на пулю № 7 реагирует особо и есть одна пуля № 12, которая совсем иначе сталкивается с каждым из монстров.

E>Ну и соответсвенно в обработчике стокновения с пулей № 7 стоит if на тип монстра, и специальная обработка на эту тему, и в обработчике столкновения с пулей № 12 стоит двойная диспечерезация (у монстра вызывают метод ProcessBullet12 )

E>Смысл в том, что все обработчики просто ищутся. Всё, что нужно знать про эту конструкцию, это то, что столкновение обрабатывает пуля.

E>Хотя, конечно, и мультиметоды тут были бы более или менее уместны, просто слегка сложнее бы всё смотрелось.
E>Если бы, скажем, пуль, вроде пули №12 было бы побольше, то я бы, пожалуй и не спорил. Но вот такой задачи так и не возникло

E>(На самом деле задача совсем другая, чем игры. Типа процесс сопоставления одной из можеделей из списка с разными объектами. Некий перебор AI-гипотез, короче говоря)

У меня задача была более менее тривиальная для игрового разработчика: написать обработчик коллизий в космическом 3D шутере. Почитал Мейрса на эту тему, но ксожалению у него конкретного решения не было (был только анализ различных подходов в том числе и с использованием if else), потом наткнулся на мультиметоды Александресску, который предложил вполне готовое решение и самый большой плюс в том, что была готовая реализация в Loki

Чем мне понравился подход Александресску, так это его простотой, что может показаться странным на первый взгляд

Здравствуйте, Аноним, Вы писали:

А>Много вы от майкрософта про UML, паттерны и проч. слышите

Они просто называли их раньше по другому. Эти слова, которые вас так пугают, результат естественного процесса стандартизации.

> А покажите мне плоды трудов проповедников сложности и те огромные проекты, с которыми они справлись благодаря своим теориям.

Во-первых не проповедников сложности, а борцов с ней. А во-вторых
ВСЕ успешные крупные проекты. Начиная с винды.

А>Я не говорю что теже паттерны — плохо, в конце концов самой нужной половиной из описанных в лит-ре все и так всю жизнь пользуются, только до жуткой на них моды не знали, что это так называется.

Вот! В этом и суть. Не знали как называется. Знаешь почему провалилось строительство вавилонской башни? Каждый разговарил на своем языке.
То что написано в книге Александреску это одна из версий стандарта языка паттернов (программирования на языке предметной области) и компилятора для него (его роль пока что выполняют шаблоны С++). Естесствено слов в нем больше чем в языках программирования типа С++. Но и разница в качестве и производительности разработки программ примерно такая же, как у С++ и программировании непосредственно в машинных кодах.

И большинство проблем при применении паттернов вызвано как раз отсутсвием официального стандарта на язык паттернов и комплилятора с них. Если каждый реализует их по своему и подразумевает свое, о какой совместимости и упрощении может идти речь.

Хотя жалобы на сложность отладки шаблонов не имеют отношения к стандартизации. По мимо языка и компилятора нужен еще и отладчик более высокого уровня. Как при ошибке в программе на С++ отладчик может показать чистый машинный код и мы вынуждениы в нем разбираться, так и при ошибке в применении шаблона на показывают его кишки. Ошибки из рантайма переходят в компиляцию, что сильно улучшает надежность готовой программы.

Так же произошел естесственный процесс разделения программистов на архитекторов — пишущий на языке паттернов и кодеров — пишущих шаблоны на языке программирования. И читать заявления кодеров о том что они все могут написать без паттернов и шаблонов ей богу смешно. Все равно что "С++ маздай — ассемблер рулит". Сколько можно? Не боитесь остаться не у дел? Большую задачу можно решить сложно простыми средствами, но проще сложными

Здравствуйте, remark, Вы писали:

R>Матрица здесь действительно возможно не к месту. Ну а причём здесь матрица?
R>Имхо адекватная реализация мультиметодов должна быть как реализация просто виртуальных методов. Когда у тебя есть дефолтная реализация в базовом классе. А где надо ты её перекрываешь.
R>И для твоего примера с пулями подходит хорошо. Т.е. делаешь дефолтную реализацию. И перекрываешь для пули №7 и монстра №18. И для пули № 21 и всех монстров.

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

R>

Здравствуйте, creatman, Вы писали:

C>Ну если мне не изменяет память Александресску обозначил двойную диспечерезацию как частный случай мультиметодов. Конечно в личном опыте не приходилось делать тройную и более диспечерезацию, но возможно в каких-то научных областях это могло бы пригодиться. Например можно пофантазировать на тему, как написать симулятор столкновения частиц в ядерном реакторе. Какие архитектурные решения можно тут применить и на сколько оправданно можно использовать мультиметоды Александресску

Упаси тебя Бог применять в этой задаче мультиметоды!
Никогда не сосчитается
Такие задачи обычно считают так, что заводят какое-нибудь пространство и в нём дефуры и их эволюция типа по сетке, возможно адаптивной

Юрий!
А ты с чем собственно не согласен? С тем что мне что-то не встречалось или встречалось на практике?

Здравствуйте, Erop, Вы писали:

....
E>Собственно поинт состоит в том, что всё это виликолепие не нужно
E>Мне вполне хватает трёх умных указателей. Один для COM-объектов, и он не наш, а баблиотечный, один просто scope_guard, с запретом копирования. (На самом деле он бывает векторным и скалярным, но первый мне пока что не пригождался). Првда по историческим причинам он давно очень у нас реализован и им и пользуемся. И ещё один со счётчиком. Он предполагает, что имущество, которым он владеет является public virtual наследником некоего класса, в котором реализован счётчик.
E>Собственно больше мне ничего от умных указателей ни разу не понадобилось.

Между прочим если вы внимательно почитаете А. то в начале главы про смарт поинтеры есть мааленькая сноска. Там говориться , если есть возможность поместить счетчик в объект — это НЕОБХОДИМО сделатьи не париться ... а дальше все про СП идет речь о классах которые мы не проектировали. Жаль что многие не читают об этом.

Здравствуйте, minorlogic, Вы писали:

M>Между прочим если вы внимательно почитаете А. то в начале главы про смарт поинтеры есть мааленькая сноска. Там говориться , если есть возможность поместить счетчик в объект — это НЕОБХОДИМО сделатьи не париться ... а дальше все про СП идет речь о классах которые мы не проектировали. Жаль что многие не читают об этом.

Я вот собственно про ТОЖЕ САМОЕ!
Я собственно позитивно к книжке А. отношусь. Я негативно отношусь, если эту книжку начинают применять, так как обычно она не нужна

Здравствуйте, remark, Вы писали:

R>Здравствуйте, Erop, Вы писали:

E>>Здравствуйте, remark, Вы писали:

R>>>Вот это как раз и называется стратегиями (политиками, аспектами), о которых пишет Александреску.
R>>>Сторонники "старых и простых" технологий предпочитают создавать в этом случае 50 классов с помощью множественного наследования или более "продвинутые" используют макросы.

E>>Не, Александреску обычно пишет о навёрнутых конструкциях их шаблонов. А я написал о структуре из нескольких указателей на интерфейсы.


R>"Навёрнутые" или не "навёрнутые" — это субъективное мнение. Мне сейчас это не кажется навёрнутым. Просто другая форма записи тем же самых вещей. Не вижу никакой принципиальной разницы между включением нескольких указателей на динамические интерфейсы или включением нескольких указателей на статические интерффейсы. Синтаксис немного другой. Да, у шаблонов синтаксис порядочно сложнее, с этим согласен. Вначале снепривычки было сложно, но сейчас практически одинаково.


R>

Разница огромная в простоте чтения , а значит сопровождения и отладки.

Мы же знаем что шаблоны в С++.

1. Гадко реализованны с точки зрения синтаксиса.

2. Не задают интерфейс который будет использоваться в шпблоне.


Два этих момента снижают читаемость в разы.

Мне кажется это очень плохой пример , исключения являются очевидным механизмом , для разработчиков которые вручную делали обработку ошибок в большой системе.

К тому же кода становиться чуть ли не в 2 раза меньше, что облегчает чтение .

Т.е. использовать исключения НАМНОГО легче чем коды возврата.