Войти
ПрограммированиеФорумОбщее

Указатели на функции-члены классов (комментарии) (13 стр)

Страницы: 112 13 14 1517 Следующая »
#180
5:39, 17 апр. 2013

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

А как он по твоему будет уметь "делегировать", если не будет уметь анализировать тип цели, на которую пытается наметиться?

+ Показать

Chaos_Optima
> demo_connector не компилируется. ругается на { Den::TConnector<int(int)>
> delegat(&Free1,10); int val = delegat();  assert(val==3); }

+ Показать

Chaos_Optima
> Вот пример.

int Test1(int i, string g, bool k) { cout << "free funtion: "<<i<<' '<<g<<' '<<k<<'\n'; return 3;}
{ Den::Connector delegat(&Test1); int val = delegat(5,"hello my little pony",true);   assert(val==3); }

Ну вообще то, это не исключения. Это ассерт-защита о несоотвествии типов, или квалификаторов, или ещё чего нибудь.
В консольке должно высветится вполне себе читабельное сообщение.

+ Показать


Chaos_Optima
> Всё правильно с точки зрения языка, но у тебя будет исключение, и такую ошибку
> будут искать вечность,

+ Показать

Chaos_Optima
а что самое печальное ты не уходишь от не знания
> сигнатуры, а наоборот делаешь её ещё более жёсткой из-за того что касты
> отсутствуют,

+ Показать

Chaos_Optima
> и при этом эту сигнатуру программист должен искать в месте вызова, а не объявления

Вся моя концепция коннектора, вся моя идея о назначении и использовании коннекторов, базируется на идее 3х.

+ Показать


Chaos_Optima
> + каждый вызов должен иметь строжайше выдержанную сигнатуру,
> пример смотри выше. То есть со всех сторон одни минусы.

Я не считаю строгую типизацию минусом. Более того, я не люблю всякого рода неявные приведения. Лучше, когда в коде все просто и явно.

+ Показать


#181
5:45, 17 апр. 2013

Grey304
> Гм.. Какой сегодня год на дворе?

Grey304

 for_each(v.begin(),v.end(),[&d](const int&i){d(i);});//нельзя использовать в стандартных алгоритмах..

Коннектор разрабатывался в рамках 2003.

Поэтому нет ни лямбд, ни стандартных смартпоинтеров, ничего такого.

вещи, которые свойственны 2003 вполне себе работают:

bool StdTest(int val){  return (val>5); }
...

cout<<"\n\n\n>>>Demonstration connector with std <<<\n\n";
{ 
        int val[]={1,2,3,4,5,6,72,3,43,4,5};
        Den::Connector con(&StdTest);

        int* r = std::find_if( val, val+11, con);
        cout<<"r="<<*r<<endl;
        assert(*r==6);
}

Grey304
> На Mingw разрыв при одном агрументе раза в три, при двух - уже разов в 6.

протестируйте и TConnector тоже. И релиз заодно. В дебаге Connector выполняет проверки типов. Он же динамический.
Grey304
> Гм...

void foom(Marker m){}  //<<--- Upsss

Как ты считаешь, если программист написал аргумент по значению, то должен ли коннектор за него это дело оптимизировать?

#182
5:48, 17 апр. 2013

Chaos_Optima
> сегодня покопался немного и оказалось что у тебя ппц как всё сильно
> типизировано, в то время как у меня допускается даже такое

У меня такое в принципе не допускается. Ни с коннекторами, ни без коннекторов.

#183
5:58, 17 апр. 2013

=A=L=X=, ты все правильно говоришь. Только не совсем понятно с какой целью.
Указатели на методы такие, какие они есть. И с такими с ними приходится работать. Тебе нужно писать в комитет с такими идеями)

#184
10:20, 17 апр. 2013

Kartonagnick
> =A=L=X=, ты все правильно говоришь. Только не совсем понятно с какой целью.
> Указатели на методы такие, какие они есть. И с такими с ними приходится
> работать. Тебе нужно писать в комитет с такими идеями)

Да всё верно, это вопрос скорее в комитет.
А пишу просто чтобы раз подчеркнуть что если были бы нормальные указатели на методы, то в общем то и делегаты бы не понадобились в подавляющем большинстве случаев.
Все эти std::function и ваши велосипеды на самом деле в языке пишутся неоднократно и часто применяются только потому что нет нормальных указателей на методы.
А так - куда то там припочковываться к неизвестной заранее сингатуре с параметрами по умолчанию (bind/unbind) - это в практике нафиг никому не нужно в 99%-ах случаев.

#185
10:38, 17 апр. 2013

Kartonagnick
> Коннектор разрабатывался в рамках 2003.
> Поэтому нет ни лямбд, ни стандартных смартпоинтеров, ничего такого.
Лямбды там только потому, что в том, что выложено, какая-то фиготень с копированием.
А смарты.. Так шаблону все равно, что биндить, в чем и фокус.
Уж "убийца" function такое и должен уметь делать сейчас:
Это в 2000 году было простительно :D
Kartonagnick
> протестируйте и TConnector тоже. И релиз заодно.
Я не знаю, что вы там выложили, но в релизе оно не собирается.
Перемудрили.
Kartonagnick
> Как ты считаешь, если программист написал аргумент по значению, то должен ли
> коннектор за него это дело оптимизировать?
Тогда чем именно гордитесь? И Chaos'а, и стандартный в случае ссылок тоже никаких лишних копий не делает.

#186
11:49, 17 апр. 2013

Kartonagnick
> Это цена за динамику. Она нивилируется возможностью кастится к TConnector,
> который так же можно полноценно использовать
Зачем эта возможность вообще нужна? Я не вижу никаких достоинств у этого решения. Кто-нибудь может объяснить, я что-то упускаю?

#187
12:25, 17 апр. 2013

Kartonagnick
> А как он по твоему будет уметь "делегировать", если не будет уметь
> анализировать тип цели, на которую пытается наметиться?
зачем ему анализировать? ты задаёшь сигнатуру, а вся остальная информация о типе хранится внутри шаблона.
Kartonagnick
> Твой так умеет?
да, и даже в коде что я выкладывал я это показывал, ну кроме const я о нём как то забыл. но те что у меня в движке умеют и с const
Kartonagnick
> Как делегат догадается на какой именно нужно нацелится?
специализация шаблонов.
Kartonagnick
> Ну вообще то, это не исключения. Это ассерт-защита о несоотвествии типов, или
> квалификаторов, или ещё чего нибудь.
> В консольке должно высветится вполне себе читабельное сообщение.
ну я назвал это исключением, тем не менее асерта там не должно быть.
Kartonagnick
> Он не делает никакого неявного приведения типов. Все очень жестко.
тем и плохо, ты никак не освобождаешь пользователя от сигнатуры, а делаешь привязку к ней ещё жестче. и при этом падать приложение будет не при привязке а в момент вызова, что уж совсем капец.
Kartonagnick
> Глянут на текст сработавшего ассерта, и сразу поймут в чем дело.
> Ну или сразу глянут стек вызовов функций, тогда вообще просто.
неа не поймут, т.к. асерт будет вызыватся в момент вызова делегата, а искать проблему надо в привязке, поэтому никакой дебаг не поможет.
Kartonagnick
> В релизном коде никакой защиты не будет.
ещё хуже.
Kartonagnick
> Ты имеешь ввиду неявное приведение?
нет я о том что, чтобы правильно привязать функцию, тебе в любом случае нужно знать сигнатуру, а в твоём случае даже точную сигнатуру. ибо место вызова делегата может быть одно а вот мест привязки к нему много.
Kartonagnick
> Им глубоко безразличны сигнатуры методов друг друга.
эм.. а каким образом робот тогда будет вызывать этот метод? Он в любом случае должен знать сигнатуру.
Kartonagnick
> Вот это и есть центральное место моей концепции коннекторов. И это то, чего ты
> никак понять не можешь.
она у тебя не работает.
mData = (const MyData&)  getData(); // ты знаешь сигнатуру getData() а если тут robot.getData = Connector(world, &World::AboutUnit); World::AboutUnit это World::AboutUnit(int,float,string) то у тебя ничего не будет работать.
Kartonagnick
> Я не считаю строгую типизацию минусом. Более того, я не люблю всякого рода
> неявные приведения. Лучше, когда в коде все просто и явно.
так ты сам себе противоречишь. любишь строгость, но при этом делегат у тебя принимает любой метод, но вызывает исключительно если сигнатура совпадает, где логика?
самое забавное что твой метод будет работать с большими костылями когда метст вызова будет много и мест привязки будет много, а если ещё добавить многопоточность то вообще вилы.
Kartonagnick
> Плюсы:
> 1. Он способен выполнять любые задачи связанные с делегатами. Любой сложности.
не способен, он вообще не является по сути делегатом. Делегат должен быть по сути как функция, то есть поддерживать неявный каст, реагировать на неправильные аргументы (при вызове и при привязке) во время компиляции, твой коннектор не отвечает ни одному из требований.

#188
12:30, 17 апр. 2013

Kartonagnick
> Как ты считаешь, если программист написал аргумент по значению, то должен ли
> коннектор за него это дело оптимизировать?
у тебя будет 3 раза объект копироваться, у меня 1 как и подобает функции ))

#189
12:33, 17 апр. 2013

Grey304
> И Chaos'а, и стандартный в случае ссылок тоже никаких лишних копий не делает.
не стандартны вообще то копирует

#190
12:39, 17 апр. 2013

p.s. В релизе VS2010 в случае одного аргумента разрыв по времени со std::function составляет два раза, а вот с двумя.. Время вызова std::function и Delegate Chaos'а - в обоих случаях почти одинаково, и сопоставимо друг с другом.
А вот у этой динамики - около шести-пяти раз.
p.s.s. Не собирается в релизе MinGW. Студия съела.
p.s.s.s. Пример, конечно, не очень корректный, но разница все равно есть, даже если просто вызывать функторы в цикле.

#191
14:18, 17 апр. 2013

=A=L=X=
> это в практике нафиг никому не нужно в 99%-ах случаев.

+ Показать

Grey304
> А смарты.. Так шаблону все равно, что биндить, в чем и фокус.
> Уж "убийца" function такое и должен уметь делать сейчас:
> Это в 2000 году было простительно :D

Не понял высказывания.
Grey304
> Я не знаю, что вы там выложили, но в релизе оно не собирается.
> Перемудрили.

Была ошибка да, я уже все поправил. Вчера проверял дебаг/релиз на 2008/gcc. Все собирается.

Grey304
> Тогда чем именно гордитесь? И Chaos'а, и стандартный в случае ссылок тоже
> никаких лишних копий не делает.

+ Показать

++i++
> Зачем эта возможность вообще нужна? Я не вижу никаких достоинств у этого
> решения. Кто-нибудь может объяснить, я что-то упускаю?
+ Показать
#192
14:20, 17 апр. 2013

Chaos_Optima
> у тебя будет 3 раза объект копироваться, у меня 1 как и подобает функции ))

Окай, окай. Серьёзный довод. Поправлю момент

#193
14:24, 17 апр. 2013

Chaos_Optima
> специализация шаблонов.

struct Rabbit1
{
    operator void()(){}
    operator void()()const{}
};
[code=cpp]struct Rabbit2
{
    operator void()()const{}
};


...

Rabbit1 rabbit1; Rabbit2 rabbit2;
Delegat<void()> delegat(rabbit1); delegat();  
Delegat<void()> delegat(rabbit2); delegat();

Если не трудно, и если это не тайна, покажи на пальцах (лучше с выдержками кода), как именно твой идеальный делегат догадается на какой именно метод он должен нацелится?

Я себе вообще это не представляю без необходимости анализировать строение класса-цели.

М?

#194
14:38, 17 апр. 2013

Kartonagnick
> Не понял высказывания.

+ Показать
Страницы: 112 13 14 1517 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.