Почему функции hiredis используют void * вместо redisReply *? - PullRequest
2 голосов
/ 21 июня 2019

Я новичок в hiredis и использую v0.13. Я заметил, что функции API из hiredis.h, которые имеют дело с redisReply* объектами, все используют void*. Например,

void *redisCommand(redisContext *c, const char *format, ...);

возвращает объект redisReply* (или NULL);

int redisGetReply(redisContext *c, void **reply);

выводит объект redisReply* через reply;

void freeReplyObject(void *reply);

- это, согласно комментарию к коду, «функция для освобождения объектов ответа, которые hiredis возвращает по умолчанию».

Чего мне здесь не хватает - почему эти функции используют void* вместо redisReply*?

Ответы [ 2 ]

3 голосов
/ 21 июня 2019

Я заметил, что функции API из hiredis.h, которые имеют дело с redisReply* объектами, все используют void*

Единственный разумный способ интерпретации вашего описания - то, что вы проанализировали реализацию и обнаружили, что внутренне , она использует указатели на тип с именем redisReply, но интерфейс имеет дело с такими указатели через тип void * вместо.

Это будет механизм, заставляющий клиентов этого API обрабатывать указатели объекта ответа как непрозрачные значения . Клиенты (предположительно) не имеют определения redisReply или даже его имени, и нет объявленной связи между указателями ответа и этим типом, поэтому API явно избегает предоставления клиентам способа создания таких объектов или интерпретировать или изменять их значения, кроме как через собственные функции API. Все, что они могут сделать, это получить эти непрозрачные указатели из API и передать их обратно.

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

1 голос
/ 21 июня 2019

Общие функции часто пишутся таким образом, так как вы можете привести любой указатель к void * и void * к одному и тому же указателю (то же самое для типов указателей char) без риска и переносимости. Вы также не получите никаких предупреждений компилятора.

...