c++ Передать метод одного класса в качестве параметра для метода другого кдасса

friend не вариант?

лямбда, std::function (std::bind)

std::function + std::bind

не надо так делать

чоэтвдруг?

не надо так делать

+1

rumgot
Касскажи свой кейс, скорее всего это нужно длелать по-другому.

Или указатель на член или универсальное решение в духе std::function + лямбда/std::bind.

чоэтвдруг?

Объясни зачем существуют private/protected, по ходу найдешь ответ на свой вопрос.

Как существование private/protected влияет на возможность передать в метод колбек?

При этом данная калбэк функция должна иметь доступ к членам своего объекта через this.

Как это нарушает private/protected?

c++ Передать метод одного класса в качестве параметра для метода другого кдасса (комментарий)

Как этот пример нарушает приватность?

Колбэки существовали и использовались всегда, никакого отношения к private/protected они не имеют.

какой стандарт? Если до 11, то гугли fastdelegate, если после, то есть стандартные средства для этого.

http://www.boost.org/doc/libs/1_59_0/doc/html/signals2.html или libsigc++2 если нужно общее решение. И сигналы/слоты в Qt, разумеется.

Таки есть указатели на методы класса. Почитай хотя бы тут https://rsdn.ru/article/cpp/fastdelegate.xml#EGD

Указатели на члены не содержат в себе объект, его придётся прокидывать отдельно, что не очень удобно.

boost::bind на стороне передающего коллбэк, boost::function на стороне получающего коллбэк

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

И пишешь ты, наверное, в бинарных кодах. А чё, всё остальное — это синтаксический сахар, не меняющий сути.

Твоя задача решаема, но как тебе уже сказали, скорее всего, тебе нужно что-то другое.

Callback-и в C++ оказываются востребованы либо для связи с «необъектным» кодом, либо при кривой архитектуре. Подозреваю, что класс A может реализовать интерфейс I, и вот указатель на него можно передать в B.

Callback-и в C++ оказываются востребованы либо для связи с «необъектным» кодом, либо при кривой архитектуре.

Функторы, которые предлагается передавать в алгоритмы STL, как раз являют собой пример таких коллбэков. STL, может быть, и «необъектный», но вполне себе C++-ный.

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

За то поменяется объем портянки. Доля букв, посвященных бойлерплейту — сократится, а доля букв, посвященных смыслу вещей — возрастёт.

Как бы передать нестатический метод 1 первого объекта в нестатический метод 2 второго объекта в качестве калбэк функции

Ты хочешь неправильно.

Что хорошо опытному девелоперу на практике, то не всегда хорошо новичку в учении. ТС явно новичек и явно учится. Вот пусть и изучает основы, как все это работает.

Ты еще волшебный каст с шаблоном предложи :)

волшебный каст с шаблоном

Чо? %)

Я малось нуб в плюсах, можно мне пример, чтоб я тоже шутку понял? :)

У Саттера были специально расписаны N-способов абузинга прав доступа с целью АЦЦКОГО ХОХОТА к членам класса http://www.gotw.ca/gotw/076.htm чтоб научить всех плохому типа как делать низязя. Еще причудливые люди, узнав про форварды с имплами, любят делать ссылки на экземпляр фасада из импла (потому что отказаться от имплов уже не могут) и прочие атататы :) А потом они открывают для себя Александреску...

Callback-и в C++ оказываются востребованы либо для связи с «необъектным» кодом, либо при кривой архитектуре.

Совершенно необязательно. Очень часто бывают ситуации, когда сущность определяет, что произошло некоторое событие, но понятия не имеет что с ним дальше делать. В таких случаях удобно делегировать приняние решения какой-нибудь другой сущности (которая не всегда известна первой). Классический пример - кнопка пользовательского интерфейса. Может определить факт того, что ее нажали, но совершенно не знает, как и кто должен обрабатывать это событие. Можно конечно попробовать обмазаться паттерном «наблюдатель» или решать вопрос через наследование, но оба варианта ведут к чудовищной архитектуре. Гораздо правильнее тут использовать какой-нибудь другой callback-механизм (лично мне больше нравися концепция сигналов).