공용 API가 현재 다음과 같은 라이브러리를 평가하고 있습니다.
libengine.h
/* Handle, used for all APIs */ typedef size_t enh; /* Create new engine instance; result returned in handle */ int en_open(int mode, enh *handle); /* Start an engine */ int en_start(enh handle); /* Add a new hook to the engine; hook handle returned in h2 */ int en_add_hook(enh handle, int hooknum, enh *h2);
참고 enh여러 가지 데이터 유형 (핸들로 사용되는 일반적인 핸들, 엔진 및 후크 ).
내부적으로 이러한 API의 대부분은 "핸들"을 내부 구조에 캐스트했습니다 malloc.
engine.c
struct engine { // ... implementation details ... }; int en_open(int mode, *enh handle) { struct engine *en; en = malloc(sizeof(*en)); if (!en) return -1; // ...initialization... *handle = (enh)en; return 0; } int en_start(enh handle) { struct engine *en = (struct engine*)handle; return en->start(en); }
개인적으로, typedef특히 타입 안전성이 떨어질 때 뒤에 숨어있는 것을 싫어 합니다. ( enh, 실제로 참조하는 내용을 어떻게 알 수 있습니까?)
그래서 풀 요청을 제출하여 다음과 같은 API 변경을 제안했습니다 ( 전체 라이브러리를 수정 한 후 ).
libengine.h
struct engine; /* Forward declaration */
typedef size_t hook_h; /* Still a handle, for other reasons */
/* Create new engine instance, result returned in en */
int en_open(int mode, struct engine **en);
/* Start an engine */
int en_start(struct engine *en);
/* Add a new hook to the engine; hook handle returned in hh */
int en_add_hook(struct engine *en, int hooknum, hook_h *hh);물론 이렇게하면 내부 API 구현이 훨씬 개선되어 캐스트가 제거되고 소비자의 관점에서 유형 안전성이 유지됩니다.
libengine.c
struct engine
{
// ... implementation details ...
};
int en_open(int mode, struct engine **en)
{
struct engine *_e;
_e = malloc(sizeof(*_e));
if (!_e)
return -1;
// ...initialization...
*en = _e;
return 0;
}
int en_start(struct engine *en)
{
return en->start(en);
}다음과 같은 이유로 이것을 선호합니다.
- 추가 된 유형 안전
- 유형의 명확성 및 목적 개선
- 삭제 된 캐스트 및
typedefs - C에서 불투명 한 유형에 권장되는 패턴을 따릅니다.
그러나 프로젝트의 소유자는 풀 요청에서 멈췄습니다 (그림으로 표시).
개인적으로 나는을 노출시키는 아이디어를 좋아하지 않습니다
struct engine. 나는 아직도 현재의 방법이 더 깨끗하고 친절하다고 생각합니다.처음에는 후크 핸들에 다른 데이터 유형을 사용했지만으로 전환하기로 결정
enh했기 때문에 모든 종류의 핸들이 동일한 데이터 유형을 공유하여 단순하게 유지했습니다. 이것이 혼란스러운 경우 다른 데이터 형식을 사용할 수 있습니다.다른 사람들이이 PR에 대해 어떻게 생각하는지 봅시다.
이 라이브러리는 현재 비공개 베타 단계이므로 걱정할 소비자 코드가 많지 않습니다. 또한 이름을 약간 난독 화했습니다.
명명 된 불투명 구조체보다 불투명 핸들이 더 나은 방법은 무엇입니까?
참고 :이 질문은 Code Review 에서 닫혔습니다.