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

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

Страницы: 112 13 14 15 16 17
#240
1:42, 18 апр. 2013

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

+ Показать

Chaos_Optima
> потому что захотел XD это же очевидно сэр.
+ Показать

Chaos_Optima
> Нет, мне это ненужно, мне нужно знать только в какой момент он вызовет делегат
> и то это не всегда нужно.

+ Показать

Chaos_Optima
> потому что у тебя сигнатура зависит не от типа делегата от аргументов вызова
> делегата, соответственно, если твой делегат в определённом месте будет вызван
> по другому, то произойдёт падение.

+ Показать

Chaos_Optima
> XD да ты хрень несёшь. Протокол передачи данных это у тебя что тип возврата?
> Так у делегата основная суть не возвращаемое значение а сам вызов, 90%
> используемых делегатов имеют возвращаемый тип void.

+ Показать

#241
2:18, 18 апр. 2013

Kartonagnick
> Делегат прислал не те данные, потому что на 1й точке его связали не с тем
> поставщиком.
в случае с шаблонным делегатом это невозможно, иначе код не будет компилиться
Kartonagnick
> Не каждый поставщик подойдет конкретному потребителю.
Каждый, любой из тех кто соответствует сигнатуре подойдёт.
Kartonagnick
> Или выбирай в слепую.
яже сказал всё что мне надо так это знать  в какой момент он вызовет делегат, я знаю допустим, что этот делегат вызывает функцию когда ему нужно топливо например, и я привязываю функцию которая обрабатывает этот вызов, но внутри она не обязательна должна его кормить.
(и да на всякий случай, знать когда вызовется делегат или при каких условиях, и знать что от него хотят это разные вещи)
Kartonagnick
> Фраза "сигнатура зависит не от типа делегата..." не корректная. Сигнатура цели
> вообще не зависит ни от кого, кроме функции, которую определяет.
в твоих делегатах, сигнатура определяется при попытке вызова, у меня же сигнатура определена, при определении типа делегата.
Kartonagnick
> Ошибки времени выполнения - неизбежная цена за динамику.
а зачем нужна динамика?
Kartonagnick
> Тот факт, что Connector умеет обеспечивать типобезопасность есть признак его
> работоспособности, а не наоборот.
Вообщето он утебя не обеспечивает типо безопасность, а делает просто строгую типизацию.
Kartonagnick
> на чем основано это утверждение?
ты читать не умеешь?
> если твой делегат в определённом месте будет вызван
> по другому, то произойдёт падение.

Kartonagnick
> Итого: моё решение позволяет сосредоточится на работе с клиентским кодом, а не
> на велосепидированнии очередной педальной эвент систем, пытаясь заткнуть ею
> дырки куцих статик-делегатов.
нет не позволяет, зато  100% заставит дебажить код до посинения.
Kartonagnick
> Такая мера позволит избежать целого класса ошибок.
да только в твоих делегатах полностью отсутствуют протокол делегата, протокол передачи данных, протокол взаимодействия между компонентами 
и ты так и не сказал чем отличается протокол делегата от протокол передачи данных и сигнатура вызова.

#242
8:49, 18 апр. 2013

Kartonagnick
> Факт, что коннектор проверяет времени выполнения нисколько не умоляет его
> функциональности.
Конечно же это не так, отсутствие компайл-тайм проверок это огромный минус.

Kartonagnick
> Факт, что он легко кастит к TConnector и обратно, что является неоспоримым
> преимуществом по сравнению с шаблонными версиями.
Это нинужно вообще. Проблемы которые в думаете что решили этим способом, нужно решать по другому.

Kartonagnick
> Факт, что на сложных задачах, типа Алксовой
А где он об этом пишет, неохота весь тред перечитывать.

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

#243
19:49, 19 апр. 2013

Chaos_Optima
> ты читать не умеешь?

Любая программа теоретически может грохнуться в рантайме, если кто-то что-то не так вызовет. И что? По твоему любая программа - не рабочая?
Что за херь ты несешь?

std::vector пасет выход за пределы диапазона в рантайме. Теоретически он может грохнуться.

Одно из двух: либо std::vector не рабочий механизм, либо ты - балоболка.

Chaos_Optima
> в твоих делегатах, сигнатура определяется при попытке вызова, у меня же
> сигнатура определена, при определении типа делегата.

И если до тебя ещё не доперло, у меня их два: динамический и статический. Статический выполняет все проверки времени компиляции.

#244
20:14, 19 апр. 2013

Kartonagnick
> Любая программа теоретически может грохнуться в рантайме, если кто-то что-то не
> так вызовет. И что? По твоему любая программа - не рабочая?
> Что за херь ты несешь?
> std::vector пасет выход за пределы диапазона в рантайме. Теоретически он может
> грохнуться.
> Одно из двух: либо std::vector не рабочий механизм, либо ты - балоболка.
facepalm. с тобой бесполезно говорить.
Kartonagnick
> И если до тебя ещё не доперло, у меня их два: динамический и статический.
> Статический выполняет все проверки времени компиляции.
я не говорю про статический, со статическим всё понятно.

#245
20:20, 19 апр. 2013

++i++
> А где он об этом пишет, неохота весь тред перечитывать.

Ничем не могу помочь.

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

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

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

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

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

Вот когда ты решишь задачку Алкса, так, что бы это было "статическое решение", вот тогда и поговорим о нужности динамики.

#246
20:22, 19 апр. 2013

Chaos_Optima
> facepalm. с тобой бесполезно говорить.

ню-ню.

Ты сказал, что Connector не работает. Не потому что он не способен выполнять свою работу, а потому что он проверяет ошибки пользователя в рантайме.

Тебе не кажется, что ты слегка загоняешься?

#247
22:29, 19 апр. 2013

Kartonagnick
> Почему я привожу в качестве довода задачу Алкса: там этот момент ярко
> выражается.
Интересно, вы об существовании языка Lua знаете?
Как там нетипизированный делегат поможет в биндинге функций?

#248
12:49, 20 апр. 2013

Kartonagnick
> Мой поинт в том, что решение основанное на статических делегатах всегда можно решить при помощи ОО-архитектуры.
И что? "Можно" != "Нужно". Можно решение на чистом С написать которое делает то же самое, вот только нужно ли? С таким подходом можно и до брейнфака дойти.

Kartonagnick
> Статические делегаты - лишь более удобный способ решений, который может
> сэкономить время и объем клиентского кода при решении специфических задач.
То что вместо написание boilerplate кода вида "class HurrDurrButtonHandler", можно просто сделать и передать делегат, это ключевое преимущество, а вовсе не какая-то второстепенная мелочь.

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

Страницы: 112 13 14 15 16 17
ПрограммированиеФорумОбщее

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