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

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

Страницы: 1 2 3 417 Следующая »
#15
11:41, 20 фев. 2013

ITcrusader
Вы используете стандартные библиотеки ?
Самый простой пример - сортировка вектора/списка с использованием сторонней функции для сравнения элементов.


#16
11:59, 20 фев. 2013

Ну либо я перегружаю "<", либо создаю, например, функциональный объект для таких целей.

#17
12:11, 20 фев. 2013

ITcrusader
> НО пока не нашел достойного примера применения. Если таков имеется, с удовольствием бы глянул:)
Замена толстого switch.
Допустим приходят к нам данные. В этих данных имеется поле CodeData. И нам нужно распарсить эти данные в зависимости от CodeData.
Значения в CodeData могут быть допустим от 0 до 100500.
Если делать через switch, то потратится некоторое время пока дойдет до ветки с 100499. Где и происходит парсинг.
А если же парсинг данных загнать в функции. А в массив загнать указатели на функции. То по CodeData можно сразу передать данные для парсинга в нужную функцию.

#18
12:19, 20 фев. 2013

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

#19
12:22, 20 фев. 2013

Идея ясна, есть набор адресов, пускай даже 1000 парсеров, любой из которых можно за постоянное время вызвать по имеющемуся индексу. Просто я, например, воспользовался классом протоколом Parser, от которого унаследовал бы множество парсеров, переопределяющих функцию Parse. А в массиве хранил бы адреса этих парсеров. И пользовался бы полиморфизмом. Может, я тут проглядел какие-то недостатки?))

#20
12:23, 20 фев. 2013

asvp
> Замена толстого switch.
> Допустим...

В ООП-нутых языках большая часть switch-ей разруливается просто виртуальными функциями. А более заковыристые случаи - делегатами.
В С++ отсутствуют нормальные делегаты и указатели на функции не могут покрыть их функционал. В результате указатели на функции действительно не имеют мест для применения. Я по крайней мере тоже таковых не видел никогда.

#21
12:26, 20 фев. 2013

ITcrusader
> Идея ясна, есть набор адресов, пускай даже 1000 парсеров, любой из которых
> можно за постоянное время вызвать по имеющемуся индексу. Просто я, например,
> воспользовался классом протоколом Parser, от которого унаследовал бы множество
> парсеров, переопределяющих функцию Parse. А в массиве хранил бы адреса этих
> парсеров. И пользовался бы полиморфизмом. Может, я тут проглядел какие-то
> недостатки?))

Собственно, описанное выше и есть по сути делегирование полиморфному классу задачи парсинга данных? Если да, то я до сих пор не верю в целесообразность использования указателей на функции члены класса:)

#22
12:41, 20 фев. 2013

=A=L=X=
> В ООП-нутых языках большая часть switch-ей разруливается просто виртуальными функциями.
100500 классов наследований?

#23
12:42, 20 фев. 2013

Вот, кстати, главная проблема указателей на функции:
http://ideone.com/L5K3SW
О каком тут реальном применении может идти речь?

P.S.

Единственно - более-менее подобные делегатам штуки (как то std::function) на каком то уровне реализованы через указатели на функции конечно же. Но это именно что решение проблемы которой и не было бы если бы в языке сразу были бы не указатели на функции, а именно делегаты.

#24
12:44, 20 фев. 2013

asvp
> 100500 классов наследований?

В большинстве случаев - да, как ни странно. Ты наверное не заметил что я написал "...большая часть switch-ей...".

#25
12:49, 20 фев. 2013

=A=L=X=
> В большинстве случаев - да, как ни странно. Ты наверное не заметил что я написал "большинство switch-ей".
Не-е. Для меня не есть гуд решение. А лазанье по vtbl дороже обойдется, чем сам switch.
ИМХО указатели на функции (или на методы класса) "хорошее блюдо". Просто его нужно правильно готовить. И употреблять только с водкой.

#26
12:51, 20 фев. 2013

asvp
> Просто его нужно правильно готовить.

Ну так объясни как ты его готовишь ввиду поста #23. Как ты можешь реально им пользоваться ввиду наличия сего ограничения?

#27
12:51, 20 фев. 2013

asvp
> 100500 классов наследований?

Ну я на это отвечу нехитрым вопросом:

100500 функций парсеров членов класса?)))

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

#28
12:56, 20 фев. 2013

ITcrusader
Для каждой задачи свои решения. Вот таким будет мой ответ.
А пример не на выдуманный. Реально было в проекте парсинг данных. Вариантов этих данных было порядка 50.

#29
13:05, 20 фев. 2013

asvp
> Реально было в проекте парсинг данных.

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

P.S.

Причём делегаты умеют решать и задачу с парсером, которую ты описал так же легко как указатели на методы, но и гораздо более широкий спектр кэллбэков. Поэтому еще раз: указатели на методы не нужны, нужны делегаты.
Но на самом деле указатели на методы умеют кое что что не умеют делегаты. Вопрос в том - а нужно ли именно вот это что они умеют и не умеют другие техники?
Ага.
Так что же это такое?
А это то что указатель на метод оторван от объекта к которому может быть применен (делегат навсегда связывается с указателем на объект при создании) и может быть вызыван на любой объект некоторого класса в рантайме. Т.е. в некоторых пределах (ограничиваясь наследниками конкретного класса и только его, этого конкретного класса методами) ты можешь подставлять объекты в вызов одного и того же указателя на метод. Нужен ли этот функционал? Есть примеры именно его применения?
Сразу скажу - что моё мнение: не нужен, реальных полезных применений нет, поэтому Страуструп совершил ошибку и вместо реально нужных делегатов создал избыточную и ненужную конструкцию указателей на методы.

Страницы: 1 2 3 417 Следующая »
ПрограммированиеФорумОбщее

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