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

R>У нас тоже был один препод, который любил считать "так, значит у списка в этом случае вычислительная сложность будет O(1), значит используем список", эх, профайлер бы ему в руки

Кстати, не так уж он был направ — зависит от требований к масштабируемости, imho

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

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

А>>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр.
А>ИМХО, "стратегии", "паттерны" так бешенно популярны, потому как осилить все мировые запасы информации на эту тему проще, чем одну главу у Кнута. Потом ходишь и слова разные такие умные говоришь, все уважают. А какой прок от Кнута? (шучу, разумеется).

А>Положа руку на сердце — ведь то, что описано в любой лит-ре по дизайну/паттернам — доступно пониманию ребёнка. Берём для сравнения какую-нибудь книгу по, например, ЦОС, сжатию данных — упс — без определённой подготовки — далеко не уедешь.

А>Я не против паттернов, но: теоретическое знание паттернов — это то, что дёшего приобретают, но норовят дорого продавать. Спекуляцией попахивает. Любой нормальный программист с опытом от 3-5 лет и больше знает кучу паттернов, даже если никогда не штудировал эту тему специально. Пролистать соотств. лит-ру и такому не мешает, но каких либо великие откровения мало-мальски опытные программисты там вряд ли смогут обнаружить. Просьба не ссылатся на отдельных дебилов которые это утверждение якобы опровергают фактом своего существования.

Может быть и доступно пониманию ребенка СЕЙЧАС, но надо иметь в виду, что "Паттерны" Банды Четырех были выпущены в 1995 году, а написаны еще раньше. В то время многие в этой стране и не задумывались о том, что такое Наблюдатели, Посетители, Фабрики и прочее. Как никак этим идеям уже почти 12 лет, так что восхищаться и бить себя кулаком в грудь по поводу паттернов как-то глупо. Это просто классика, общий язык — и его надо знать.

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

А>Попались мне давеча книжки Александреску. Прочитав немного, понял, что плохо понимаю о чем идет речь: "шаблоны", "стратегии", "паттерны" и пр.
А>Но интуиция подсказывает, что это то, чего не хватает мне, чтобы перейти с традиционного С/С++ программирования на новый более высокий уровень .
А>Если более опытные товарищи, подкинут ссылки или книжку толковую посоветуют, буду очень признателен. А то чувствую себя пещерным человеком ))

Х. Дейтел, П. Дейтел. Все понятно, доходчиво, структурировано. Кул и маст хэв.

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

E>3) Ещё Александреску конечно очень хорошо показал, что шаблоны C++ можно использовать как очень плохую и неудобную и практически неолаживаемую версию языка Prolog. Но совсем не раскрыл тему "зачем так извращаться?" Может лучше пролог заботать да и писать макеты на нём, ну а в реализации это всё скорее всего не нужно будет

Не Prolog только конечно, а LISP. LISP — это "отец" функционального и обобщенного программирования.

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

AA>Может быть и доступно пониманию ребенка СЕЙЧАС, но надо иметь в виду, что "Паттерны" Банды Четырех были выпущены в 1995 году, а написаны еще раньше. В то время многие в этой стране и не задумывались о том, что такое Наблюдатели, Посетители, Фабрики и прочее. Как никак этим идеям уже почти 12 лет, так что восхищаться и бить себя кулаком в грудь по поводу паттернов как-то глупо. Это просто классика, общий язык — и его надо знать.
Паттерны во многом по идеям Коплиена написаны... А он свою книжку выпустил в 1992 году.. Значит, думал — еще раньше...

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

А>ИМХО, "стратегии", "паттерны" так бешенно популярны, потому как осилить все мировые запасы информации на эту тему проще, чем одну главу у Кнута. Потом ходишь и слова разные такие умные говоришь, все уважают. А какой прок от Кнута? (шучу, разумеется).

А>Положа руку на сердце — ведь то, что описано в любой лит-ре по дизайну/паттернам — доступно пониманию ребёнка. Берём для сравнения какую-нибудь книгу по, например, ЦОС, сжатию данных — упс — без определённой подготовки — далеко не уедешь.

А>Я не против паттернов, но: теоретическое знание паттернов — это то, что дёшего приобретают, но норовят дорого продавать. Спекуляцией попахивает. Любой нормальный программист с опытом от 3-5 лет и больше знает кучу паттернов, даже если никогда не штудировал эту тему специально. Пролистать соотств. лит-ру и такому не мешает, но каких либо великие откровения мало-мальски опытные программисты там вряд ли смогут обнаружить. Просьба не ссылатся на отдельных дебилов которые это утверждение якобы опровергают фактом своего существования.

Супер! А то развели истерию- паттерны, шаблоны проектирования, мы крутые раз можем писать шаблонный код и имеем "шаблонное" мышление. А задачи для школьников 6-го класса (математического) никто решить не может. Реально сложные вещи- алгоритмы и логические задачи. В С++ и шаблонах/паттернах/whatever ничего сложного нет.

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

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

AG>Супер! А то развели истерию- паттерны, шаблоны проектирования, мы крутые раз можем писать шаблонный код и имеем "шаблонное" мышление. А задачи для школьников 6-го класса (математического) никто решить не может. Реально сложные вещи- алгоритмы и логические задачи. В С++ и шаблонах/паттернах/whatever ничего сложного нет.

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

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

AA>Какой ты предлагаешь сделать вывод из сказанного тобой? Что одно нужно, а другое нет? Что надо учить алгоритмы, а паттерны нафиг? Боюсь свести беседу к банальностям, но тем не менее: алгоритмы — средство решения сложных вычислительных задач, а паттерны — средство локализации процесса решения сложных задач. Написать расширяемую, легко поддерживаемую систему на одних алгоритмах не получится.

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

E>>3) Ещё Александреску конечно очень хорошо показал, что шаблоны C++ можно использовать как очень плохую и неудобную и практически неолаживаемую версию языка Prolog. Но совсем не раскрыл тему "зачем так извращаться?" Может лучше пролог заботать да и писать макеты на нём, ну а в реализации это всё скорее всего не нужно будет

MZ>Не Prolog только конечно, а LISP. LISP — это "отец" функционального и обобщенного программирования.

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

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

S>ЗЫ Естественно, можно и глобальный объект сделать как PIMPL с IMPL, создающимся по требованию, но это уже Синглетон , хотя в паттернах нет явных границ, так что как хотите так и называйте.

А зачем это всё нужно?

Если речь идёт о объекте который создаётся где-то по ходу работы программы, то не ясно зачем такие громкие слова и какие-то хитрые паттерны.

А если речь идёт о создании статических объектов (обычно эта тема оказывается рядом с синглетонами ), то ИМХО от этого один только вред

здесь

Автор: alexeiz
Дата: 15.04.06

и ниже по дереву

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

R>Ну я надеюсь, что он хотя бы типобезопасный, а не на void* работает
R>И ещё надеюсь, что мне, что бы захранить в таком контейнере какой-то класс, не надо вначале реализовывать интерфейс IStorable
Спасибо за то, что надеешься, что у нас всё хорошо
И это так. Всё хорошо и довольно удобно. Лично мне нравится не всё, но намного лучше, чем stl::vector

Quasi!
А ты не веришь что у кого-то получится?
Или что получится не у всех?

R>>Я совершенно согласен, что мультиметоды вещь достаточно редкая, поэтому к ним такое и отношение. Но А тут совершенно ни при чём. Он лишь предложил достаточно хорошую реализацию мультиметодов. Но в том, что это редкая вещь, он не виноват.
E>Крнечно не виноват! Это его заслуга, что он смог придумать столь редкую задачу и решение для неё. Просто вся эта штука очень далека от реальной жизни
E>А виноват чувак, который решает внедрить мультиметоды туда, где они не нужны. Потому что так "покруче" будет

Назначение мультиметодов помоему хорошо описаны у Саттера (Правило 31 кажется). Я их лично использовал для реализации физики при разработке движка игры.

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

R>>>Я совершенно согласен, что мультиметоды вещь достаточно редкая, поэтому к ним такое и отношение. Но А тут совершенно ни при чём. Он лишь предложил достаточно хорошую реализацию мультиметодов. Но в том, что это редкая вещь, он не виноват.
E>>Крнечно не виноват! Это его заслуга, что он смог придумать столь редкую задачу и решение для неё. Просто вся эта штука очень далека от реальной жизни
E>>А виноват чувак, который решает внедрить мультиметоды туда, где они не нужны. Потому что так "покруче" будет

C>Назначение мультиметодов помоему хорошо описаны у Саттера (Правило 31 кажется). Я их лично использовал для реализации физики при разработке движка игры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Двойная диспетчеризация — есть способ реализации мультиметодов. Так же как switch-on-type есть способ реализации динамического полиморфизма.
Если есть 2 или более типов и код, который необходимо выполнить, зависит от этих типов, то это мультиметод. По определению. А как их реализовывать — это уже другой вопрос. С помощью if'ов, двойной диспетчеризации, шаблонных наворотов, или с помощью поддержки в языке.

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

R>Двойная диспетчеризация — есть способ реализации мультиметодов. Так же как switch-on-type есть способ реализации динамического полиморфизма.
R>Если есть 2 или более типов и код, который необходимо выполнить, зависит от этих типов, то это мультиметод. По определению. А как их реализовывать — это уже другой вопрос. С помощью if'ов, двойной диспетчеризации, шаблонных наворотов, или с помощью поддержки в языке.

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

Ну типа там почти во всех клетках был дефолтный какой-то обработчик, и какой-то столбик или строка были заполнены.
Ну и ещё где-то в нескольких местах были другие обработчики.

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

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

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

E>>... стоит сменить C++ на что-нибудь менее простое и более непонятное.


I>Так ведь нет ничего такого...

машинные коды еще никто не отменял
там и Хелов Ворлд будет выглядеть крайне круто и закручено

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

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

R>>Двойная диспетчеризация — есть способ реализации мультиметодов. Так же как switch-on-type есть способ реализации динамического полиморфизма.
R>>Если есть 2 или более типов и код, который необходимо выполнить, зависит от этих типов, то это мультиметод. По определению. А как их реализовывать — это уже другой вопрос. С помощью if'ов, двойной диспетчеризации, шаблонных наворотов, или с помощью поддержки в языке.

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

E>Ну типа там почти во всех клетках был дефолтный какой-то обработчик, и какой-то столбик или строка были заполнены.
E>Ну и ещё где-то в нескольких местах были другие обработчики.

E>Собственно мне кажется, что специальная сложная реализация этой матрицы, которая умеет делать всё хорошо для случая невырожденной матрицы, оказывается излишней в случае вырожденной. Про это речь собсвтенно


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