Структура функций, В чём преимущество ? Опции

[pokk]

Здравствуйте, есть вот такая хитрая структура (тут мне не совсем понятно что делает union и зачем он там нужен)

CODE

typedef struct __WIZCHIP
{
uint16_t if_mode; ///< host interface mode
uint8_t id[6]; ///< @b WIZCHIP ID such as @b 5100, @b 5200, @b 5500, and so on.
/**
* The set of critical section callback func.
*/
struct _CRIS
{
void (*_enter) (void); ///< crtical section enter
void (*_exit) (void); ///< critial section exit
}CRIS;
/**
* The set of @ref\_WIZCHIP_ select control callback func.
*/
struct _CS
{
void (*_select) (void); ///< @ref \_WIZCHIP_ selected
void (*_deselect)(void); ///< @ref \_WIZCHIP_ deselected
}CS;
/**
* The set of interface IO callback func.
*/
union _IF
{
/**
* For BUS interface IO
*/
struct
{
uint8_t (*_read_byte) (uint32_t AddrSel);
void (*_write_byte) (uint32_t AddrSel, uint8_t wb);
}BUS;
/**
* For SPI interface IO
*/
struct
{
uint8_t (*_read_byte) (void);
void (*_write_byte) (uint8_t wb);
}SPI;
// To be added
//
}IF;
}_WIZCHIP;

Заполнение её (.if_mode .id и др указывают место расположение ? т.е при таком подходе можно их местами менять ? )

Код

_WIZCHIP  WIZCHIP =
      {
      .id                  = _WIZCHIP_ID_,
      .if_mode             = _WIZCHIP_IO_MODE_,
      .CRIS._enter         = wizchip_cris_enter,
      .CRIS._exit          = wizchip_cris_exit,
      .CS._select          = wizchip_cs_select,
      .CS._deselect        = wizchip_cs_deselect,
      .IF.BUS._read_byte   = wizchip_bus_readbyte,
      .IF.BUS._write_byte  = wizchip_bus_writebyte
//    .IF.SPI._read_byte   = wizchip_spi_readbyte,
//    .IF.SPI._write_byte  = wizchip_spi_writebyte
      };

Работа с ней выглядит так

Код

WIZCHIP.CS._select();

т.е получается просто вызывается функция wizchip_cs_select()

Так вот чём преимущество такого подхода WIZCHIP.CS._select(); по сравнению с просто вызовом функции wizchip_cs_select(); ?
И на сколько дольше выполняется первый метод по сравнению со вторым?

[AHTOXA]

А разве может быть иное?

Да. Функция может не вызывать переданный ей параметр-функцию в процессе своей работы
Может просто сохранить в переменной, например. Или возвращать адрес функции-параметра.

Неубедительно.

Вы не согласны с тем, что параметр функции qsort() является callback-ом? Так это не я придумал, это общепринято.
То, что вы с A. Fig Lee считаете callback'ом - это асинхронный callback, частный случай callback'а. Вот вам, например, статья про сравнение асинхронных и синхронных callback'ов. Там есть и определения для этих двух вариантов.

Всё-таки где отличия от параметра-функции или это 100% аналог?

Вот выше я привёл два примера функции-параметра, не являющихся callback'ами. Но обычно эти понятия синонимы.

[A. Fig Lee]

Вы не согласны с тем, что параметр функции qsort() является callback-ом? Так это не я придумал, это общепринято.

CC2520 не является Zigbee трансивером, но в мануале она так обзывается.
Если нет факта callbacka, значит это не callback.
qsort, это ни какой ни бэк, это последовательная енумерация.
Без всяких коллов и бэков.

[GetSmart]

Если нет факта callbacka, значит это не callback.

Голосуем. Кто за этот вариант?
А то чёткость признаков отсутствует.

Файловая система например обычно на уровень выше драйвера устройства хранения.

Драйвер устройства хранения вызывает функции файловой системы?

[AHTOXA]

Голосуем. Кто за этот вариант?

Да, это стопудово верный вариант. Осталось выяснить, что такое факты callback'а