Указатели на функции-члены классов (комментарии) (15 стр) / Общее / Форум / Программирование игр / GameDev.ru

Kartonagnick
> А я вот просто уверен, что прежде чем назначить потребителю поставщика тебе
> придется понять, что именно хочет потребитель, и что именно предоставляет
> поставщик. Тююю...
Лол. Над чем смеетесь?
Зная сигнатуру, я уже сужаю круг методов.
Kartonagnick
> А теперь представь себе, что в проекте множество компонентов, с множеством
> методов.
И чем ваш тут коннектор поможет? Когда эти компоненты должны еще и во время исполнения подгружаться согласно конфигам? Да модули будут еще не одинаковыми компиляторами собраны?
Нее, тут рулит исключительно эмуляция динамики поверх чистейшей статики. А type_info и динамик касты идут лесом.

++i++
Постоялец

#211
18:50, 17 апр 2013

Kartonagnick
> У земли два метода, возвращающие int. Какой именно?
Тот который нам нужен, очевидно.

Kartonagnick
> Ты почему то думаешь, что потребитель по дефолту сожрет все что угодно, лишь бы
> оно отвечало протоколу делегата.
А почему должно быть по другому?

Kartonagnick
> Программисту 1й точки нужно совершенно четко осознавать какие услуги он
> определяет для потребителей.
Нет же, главный поинт делегатов как раз в том, что никто ни о ком ничего не знает. Мы передаем кому-то std::function, кто-то ее когда-нибудь дергает.

Kartonagnick
> Один из методов может вернуть погоду в мире. А другой - остаток жратвы. А
> третий ещё что то.
> Что получится, если роботу назначат погоду вместо жратвы?
Боретесь с проблемами которые сами же и сделали? Понятно....

Kartonagnick
Постоялец

#212
19:07, 17 апр 2013

Chaos_Optima
> а причём тут костыльная архитектура?

Ну давай поговорим за архитектуру.
Я знаю две схемы связей с делегами. Все они имеют свои плюсы и минусы:

+ Показать

− Скрыть

1. Круговая схема. Робот захотел жрать. Он излучает в эфир "хочу жрать" . И дальше идет по своим делам. Он лишь уведомляет, но не ждет ответа. Связь односторонняя.

Земля же, уловив сигнал от робота, может в свою очередь послать ему сигнал - "иди в первую локацию".
Идущий по своим делам робот, улавливает сигнал, и прется в первую локацию. А там - жратва и он жрет.

Плюсы: возможность для поставщиков услуг отложить принятие решения. Например, поставить полученный запрос куда нить в очередь, или дальше переправить его на сервер, и не отвечать, пока от сервера не придет ответ.

Минусы: при косячной архитектуре может так получится, что сигнал робота улетел к земле и хз - где-то там затерялся. Земля, что бы принять решение ещё куда то его отправила. Там ещё куда то. кто-то что бы принять решение послал запросы ещё куда то, и бла бла бла. А потом оказалось, что какой нибудь объект сдох по дороге.
Ладно если сегфолд. А то может быть робот просто ослеп.

Другой минус: не известно по какому пути придет ответ к роботу. Кто-то удаленно может запустить какой угодно его метод.
Поэтому, если что-то пошло через жёпь, особенно, если код чужой, и многоярусный - становится крайне не очевидным: а что вообще может (должно) произойти на запрос робота? Откуда ждать возможные ответы?

Нужно было вынести работу клиента игрушки в отдельный поток. Вынес. Оказалось, эта мерзопакость толкала длинюююющуюююю петлю всякой шняги. Часть из которой оказалась залипающая. И эти залипания воздействовали на бизнес-логику основного потока.

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

+ Показать

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

Если возникают проблемы: что бы разобраться, приходится раскручивать всю цепочку от начала запроса до получения ответа. Исследовать бизнес-логику всех этих посредников. Протоколы функций - это последнее, что будет интересовать при такой отладке.

Kartonagnick
Постоялец

#213
19:19, 17 апр 2013

Grey304
> Лол. Над чем смеетесь?
> Зная сигнатуру, я уже сужаю круг методов.

А я вот ничего не сужаю. Я сразу знаю. И наверняка. И что уже писал выше и неоднократно: программирование с делегатами, это программирование в терминах протокола передачи данных, а не сигнатуры. Плевать на сигнатуру. Ложить сверху и сприбором. Она никак делу не помогает.

+ Показать

− Скрыть

void GetData(For_Robot& ); //Имя типа сообщения ни с чем ничайно не спутаешь. 
   //Оно выступает гарантом того, что поставщик отдает себе отчет в том, что отправляет
          //А робот сумеет корректно прочитать сообщение.

И все, никаких проблем.

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

Я могу ткнуть роботу connector в конструкторе. И он уже в конструкторе, один раз проверит - соотвествует ли протокол-имя-сообщения требуемому.
Конечно, ошибка все равно будет только в рантайме. Но она будет в моменте инициализации (время работы 1й точки), а не время использования (2,3 точки).

Конечно, TConnector может сделать все тоже самое ещё лучше. И нет резона использовать универсальный Connector для задачи, где лучше справится узко-специализированный TConnector.

И конечно, сигнатура функций с которыми работают непосредственно делегаты совершенно монописуальны самим потребителями и поставщикам.
Плевать на сигнатуру. Главное - иметь возможность проконтролировать, что удаленный метод поставщика читает/пишет именно в таком формате данные, в каком это нужно

Kartonagnick
Постоялец

#214
19:25, 17 апр 2013

++i++
> Тот который нам нужен, очевидно.

Как ты определишь какой именно метод тебе нужен, Кэп?

++i++
> Нет же, главный поинт делегатов как раз в том, что никто ни о ком ничего не
> знает. Мы передаем кому-то std::function, кто-то ее когда-нибудь дергает.

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

Добро пожаловать на 1ю точку.
++i++
> Боретесь с проблемами которые сами же и сделали? Понятно....

Я там привел пример: два метода есть у земли. Оба они отвечают протоколу <int()>
Как ты узнаешь, какой именно метод нужно поставить роботу?

Реши эту проблему без моего коннектора. А я посмотрю, чем твоё решение, скажем с использованием std::function будет отличатся от решения с использованием любого другого делегата

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

Grey304
Удалён

#215
19:29, 17 апр 2013

Kartonagnick
> А я вот ничего не сужаю. Я сразу знаю. И наверняка
Мда, вы мастер демагогии и передергиваний 90 уровня.
То на требование описать, какой функтор Роботу нужен требуете разбираться в куче методов, с не говорящими именами и которые возвращают ничего не говорящий int.
То сами начинаете давать методам Мира ( какая земля? Мир, World лучше описывает это) очень даже говорящие типы.
И кстати, вот это -
void GetData(For_Robot& );
- петля. "Мир" не должен интересоваться конкретным роботом.
Это Робот должен знать, что с Миром можно сделать.
Или наоборот - класс "Робот" уже готов и неизменяем. А вот класс "Мир" придется делать с учетом "Робота".

Kartonagnick
Постоялец

#216
19:37, 17 апр 2013

Grey304
> Мда, вы мастер демагогии и передергиваний 90 уровня.

Я утверждаю, что при работе с делегатами критичен протокол передачи данных (набор правил, по которым определяется, как правильно отправлять/получать данные).
И плевать на сигнатуру функций.

И в чем демагогия?

Grey304
> - петля. "Мир" не должен интересоваться конкретным роботом.
> Это Робот должен знать, что с Миром можно сделать.

На самом деле никто не никому ничего не должен. Робот не знает ни о каком мире. Он лишь помечает собственные сигналы своими метками, и читает извне нечто со своими метками.

С землей Аналогично.

Kartonagnick
Постоялец

#217
19:45, 17 апр 2013

Grey304
> Все. Больше я там ничего не трогал))

Что то я не уловил в этой выдержке кода, как он может нацелится на константный метод. И как он выбирает между константной или неконстатной версиями

Grey304
Удалён

#218
20:07, 17 апр 2013

Kartonagnick
> Я утверждаю, что при работе с делегатами критичен протокол передачи данных
> (набор правил, по которым определяется, как правильно отправлять/получать
> данные).
> И плевать на сигнатуру функций.
> И в чем демагогия?
В том, что сигнатура функций - это и есть "что при работе с делегатами критичен протокол передачи данных (набор правил, по которым определяется, как правильно отправлять/получать данные)."

Вы сами привели примеры, где все типы известны на момент связывания. И типы там не могут взять и поменяться. Программу придется перекомпилировать. Зачем там безтиповые функторы с проверкой в рантайме?????

Kartonagnick
> На самом деле никто не никому ничего не должен. Робот не знает ни о каком мире.
> Он лишь помечает собственные сигналы своими метками, и читает извне нечто со
> своими метками.
Отлично.
Откомпилируйте это:

+ Показать

− Скрыть

Файл "DataForRobot.h"

struct DataForRobot{}

Файл "Robot.h"

#include "DataForRobot.h"
class Robot{
public:
      function<void (DataForRobot*)> _dataSource;
};

Файл "World.h"

class World{
public:
      void Get(DataForRobot*);//хрясь!! А мы не включили сюда DataForRobot.h
};

А если включим, то получим что типы World и Robot зависят от типа DataForRobot.
Ну и как эту связь разорвать?
Мы не можем сделать так, чтобы World и Robot не зависели от какого-то третьего типа.
Не можем.
И как вы подключите Робота к Миру, если Мир ничего не знает об Роботе, и выдает свои данные?
Т.е., так:
Файл "Robot.h"

class Robot{
public:
      function<void (DataForRobot*)> _dataSource;
};

Файл "World.h"

class World{
public:
      void Get(MyWorldData*);//все. других методов у World нет и быть не может.
//World умеет выдавать только данные в таком виде, и никаком другом
// И метод void Get(DataForRobot*) добавить нельзя!! 
//Потому что интерфейс World уже разработан и изменению не подлежит!!
};

Как это стыковать?

Kartonagnick
> как он может нацелится на константный метод. И как он выбирает между
> константной или неконстатной версиями
Оно не ради этого писалось.
А если надо различать - перегрузка функций - ваш лучший друг.

Chaos_Optima
Постоялец

#219
20:21, 17 апр 2013

Kartonagnick
> Странно. Потому что эту проблему я наблюдал в проекте, в котором не
> использовался мой коннектор. Там использовался std::function со всякими
> буст-биндами и ещё воз и малая тележка всякого маловразумительного добра.
там всё элементарно разруливается дебагером, у меня проблем никогда не было.
Kartonagnick
> У земли два метода, возвращающие int. Какой именно?
эм... это как бы пользователь должен решить, делегату то пофиг.
Kartonagnick
> Ты почему то думаешь, что потребитель по дефолту сожрет все что угодно, лишь бы
> оно отвечало протоколу делегата.
да, в этом и есть смысл делегатов. Ты походу реально не врубаешься для чего они нужны.
Kartonagnick
> И я просто уверен, что прежде чем назначить потребителю поставщика тебе
> придется понять, что именно хочет потребитель, и что именно предоставляет
> поставщик. Тююю...
пфф. как раз таки, я ничего и не должен знать.

Kartonagnick
> Ты никак его не освободишь от необходимости знать и о поставщике и о
> потребителе.
вот как раз таки делегаты и освобождают, в этом их смысл.
Kartonagnick
> Что получится, если роботу назначат погоду вместо жратвы?
эт как? у него делегат имеет такой вид Delegate<food()> в случае с шаблонами ты никак не назначишь ему wether().
Kartonagnick
> 1. Круговая схема. Робот захотел жрать. Он излучает в эфир "хочу жрать" . И
> дальше идет по своим делам. Он лишь уведомляет, но не ждет ответа. Связь
> одностороння
какую то фигню придумал, давай более близкое, про GUI например, там делегаты раскрывают практически весь свой потенциал.

Chaos_Optima
Постоялец

#220
20:28, 17 апр 2013

Kartonagnick
Постоялец

#221
21:50, 17 апр 2013

Chaos_Optima
> да, в этом и есть смысл делегатов. Ты походу реально не врубаешься для чего они
> нужны.

Ответь пожалуйста, какой именно метод подойдёт роботу:

class Robot
{
public:
    void setHandler(const Den::TConnector<int()>& handler);
};

class World
{
public:
    int GetData1()const;
    int GetData2()const;
};

По твоим словам, получается, что делегат робота можно настроить на любую функцию, удовлетворяющую протоколу делегата.
То есть, ты считаешь, что без разницы что именно делают эти функции, и что они возвращают, главное - что бы удовлетворяли протоколу делегата.

Ты походу сам не врубаешься для чего нужны делегаты.

Chaos_Optima
> пфф. как раз таки, я ничего и не должен знать.

Сейчас ты - программист 1й точки. Тебе нужно связать робота и землю. Для этого тебе нужно скормить роботу заряженный делегат.
Как ты будешь выбирать какой именно метод земли подойдет для робота?
Как ты будешь это делать, если ты не знаешь, что именно возвращают методы земли?

Chaos_Optima
> вот как раз таки делегаты и освобождают, в этом их смысл.

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

Chaos_Optima
> какую то фигню придумал, давай более близкое, про GUI например, там делегаты
> раскрывают практически весь свой потенциал.

Хорошо. Но прежде, чем мы двинемся дальше, я хочу увидеть, что ты понял смысл: прокол шаблонного делегата -сам по себе - ничто. Он не поможет тебе правильно установить связи между компонентами.

Сделай выбор. И объясни мне, как именно ты сделал этот выбор.
На чем ты основывался выбирая из двух методов, если она они удовлетворяют протоколу делегата робота.

++i++
Постоялец

#222
22:05, 17 апр 2013

Kartonagnick
> А кто решает, и в какой момент принимается это решение: чем заправить делегат, и кому его впихнуть?
> Как ты определишь какой именно метод тебе нужен, Кэп?
Эту проблему можно решить собрав параметры в структурку. Дать ей и данным понятное название, т.е. вместо:

    int GetData1()const;
    int GetData2()const;

будет

    struct Data1Params
    {
        int Data1;
    };
    struct Data1Params
    {
        int Data2;
    };

    Data1Params GetData1()const;
    Data2Params GetData2()const;

Подсунуть не тот делегат не туда невозможно, все проверяется компилятором. И по сигнатуре видно что где и как используется.

Kartonagnick
Постоялец

#223
22:42, 17 апр 2013

Grey304
> В том, что сигнатура функций - это и есть "что при работе с делегатами критичен
> протокол передачи данных (набор правил, по которым определяется, как правильно
> отправлять/получать данные)."
> Вы сами привели примеры, где все типы известны на момент связывания. И типы там
> не могут взять и поменяться. Программу придется перекомпилировать. Зачем там
> безтиповые функторы с проверкой в рантайме?????

+ Показать

− Скрыть

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

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

А ты попробуй решить задачку ALX`a, используя шаблонную версию делегата. Может быть тебе удастся придумать что нибудь поумнее, чем крайне неэффективное использование boost::any, как вопиющию попытку отвязаться от злополучного протокола.

Коннектор - отличное решение там, где заранее не известна сигнатура целей, и она может оказаться любой. Решается проблема и хранения, и нацеливания.
А удобный каст Connector = TConnector<Protocol>; TConnector<Protocol>= Connector; Довершает картинку.

Есть особый деспетчер. Он цепляется особым образом к любому объекту, и объект становится "умным". Можно программировать его на любые действия.
Например:

объект.ДобавитьЗадание(ИскатьВрагов(парам) )
объект.ДобавитьЗадание(ИскатьЕду(парам))
объект.ДобавитьЗадание(ЗапуститьФункцию(парам))

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

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

Сможешь придумать, как в это дело пропихнуть std::fuction ?

Правда в том, что задачи, которые решаются при помощи TConnector простые. Все их можно решить за счет ОО-архитектуры.

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

А вот задачи, где действительно требуется реальные делегаты, которые реально способны нацеливаться куда угодно и работать - там шаблонные версии вам уже не помогут. Ну или придется извращаться, как извращался ALX: std::function<boost::any(std::vector<boost::any>) >

Не хочешь постетить насколько просядет скорость работы такого извращения по сравнению с моим Connector ? А в релизе?

Grey304
> Мы не можем сделать так, чтобы World и Robot не зависели от какого-то третьего
> типа.

+ Показать

− Скрыть

Угу. Этот тип "протокол": DataForRobot
Смысли, протокол передачи данных, а не протокол делегата.

И он не принадлежит ни роботу, ни земле. Может быть протокол "погода", который сможет читать и робот, и земля. Но он тоже не будет их собственностью.
Можете и не использовать протоколы. Можете тупо поюзать что то типа: void(int), или какой нить массив простых чевотов.
Но тогда протокол делегата не даст вам гарантий работоспособности.