Словом, використовуйте,std::function якщо у вас немає причин цього не робити.
Покажчики функцій мають недолік у тому, що вони не в змозі захопити певний контекст. Наприклад, ви не зможете передавати лямбда-функцію як зворотний виклик, який фіксує деякі змінні контексту (але він буде працювати, якщо не зафіксує жодної). Викликати змінну члена об'єкта (тобто нестатичну), таким чином, також неможливо, оскільки об'єкт ( this-показник) потрібно захопити. (1)
std::function(оскільки C ++ 11) - це насамперед для зберігання функції (для передачі її навколо не потрібно зберігати). Отже, якщо ви хочете зберегти зворотний виклик, наприклад, у змінній члена, це, мабуть, ваш найкращий вибір. Але також якщо ви не зберігаєте його, це хороший "перший вибір", хоча у нього є недолік введення деяких (дуже маленьких) накладних витрат при виклику (так що в дуже критичній продуктивності ситуація може бути проблемою, але в більшості не повинно). Це дуже "універсально": якщо ви багато піклуєтесь про послідовний і читабельний код, а також не хочете думати про кожен свій вибір (тобто хочете зробити його простим), використовуйте std::functionдля кожної функції, яку ви проходите навколо.
Подумайте про третій варіант: якщо ви збираєтесь реалізувати невелику функцію, яка потім щось повідомляє через надану функцію зворотного виклику, розгляньте параметр шаблону , який може бути будь-яким об'єктом , що може викликати , тобто вказівником функції, функтором, лямбда, a std::function, ... Недолік тут полягає в тому, що ваша (зовнішня) функція стає шаблоном і тому її потрібно реалізувати в заголовку. З іншого боку, ви отримуєте перевагу в тому, що виклик до зворотного дзвінка може бути вкладений, оскільки клієнтський код вашої (зовнішньої) функції "бачить" виклик до зворотного дзвінка буде точною інформацією про тип.
Приклад для версії з параметром шаблону (запишіть &замість &&попереднього C ++ 11):
template <typename CallbackFunction>
void myFunction(..., CallbackFunction && callback) {
...
callback(...);
...
}
Як видно з наступної таблиці, всі вони мають свої переваги та недоліки:
+-------------------+--------------+---------------+----------------+
| | function ptr | std::function | template param |
+===================+==============+===============+================+
| can capture | no(1) | yes | yes |
| context variables | | | |
+-------------------+--------------+---------------+----------------+
| no call overhead | yes | no | yes |
| (see comments) | | | |
+-------------------+--------------+---------------+----------------+
| can be inlined | no | no | yes |
| (see comments) | | | |
+-------------------+--------------+---------------+----------------+
| can be stored | yes | yes | no(2) |
| in class member | | | |
+-------------------+--------------+---------------+----------------+
| can be implemented| yes | yes | no |
| outside of header | | | |
+-------------------+--------------+---------------+----------------+
| supported without | yes | no(3) | yes |
| C++11 standard | | | |
+-------------------+--------------+---------------+----------------+
| nicely readable | no | yes | (yes) |
| (my opinion) | (ugly type) | | |
+-------------------+--------------+---------------+----------------+
(1) Для вирішення цього обмеження існують обхідні шляхи, наприклад, передача додаткових даних у якості додаткових параметрів вашій (зовнішній) функції: myFunction(..., callback, data)викликає callback(data). Це "зворотний виклик з аргументами" у стилі C, який можливий у C ++ (і, до речі, широко використовується в API WIN32), але його слід уникати, оскільки в C ++ є кращі варіанти.
(2) Якщо ми не говоримо про шаблон класу, тобто клас, у якому ви зберігаєте функцію, є шаблон. Але це означало б, що на стороні клієнта тип функції визначає тип об'єкта, який зберігає зворотний виклик, що майже ніколи не є варіантом для реальних випадків використання.
(3) Для попереднього C ++ 11 використовуйте boost::function