C API를 종종이 무엇인지 묻는 내부 찌를 시도에서 소비자를 낙담 불투명 핸들를 제공 쓸 수 있습니다. 이러한 핸들이 포인터라는 사실은 중요하지 않으며 소비자에게 중요하지 않아야하며 여분의 별의 어휘가 혼란스럽지도 않습니다.
typedef void * MyHandle;
지금 우리는 행복한 C 소비자에게 일부 기능을 제공 :와
MyHandle create_gizmo();
void destroy_gizmo(MyHandle);
int do_magic(MyHandle, int, int);
간단한 예를 들어
, 그것은 핸들을 정의하여 바인딩 C++를 쓸 수 있도록 완벽하게 가능합니다. 사용자는 즉시 그것을 사용하는 방법을 본다 :
#include "MagicAPI.h"
MyHandle h = create_gizmo();
submit_result(do_magic(h, 12, 91));
destroy_gizmo(h);
그리고 C를 ++ 라이브러리 개발자는 단순히 핸들을 펼쳤다과 (extern "C"
를 선언 물론되는) API 함수를 채 웁니다 :
#include "MagicAPI.h"
#include "SuperGizmo.hpp"
MyHandle create_gizmo() { return static_cast<MyHandle>(new SuperGizmo); }
void destroy_gizmo(MyHandle h) { delete static_cast<SuperGizmo *>(h); }
int do_magic(MyHandle h, int a, int b)
{
return static_cast<SuperGizmo *>(h)->foo(a, b);
}
그것은 취향의 문제이다. 나는 당신의 입장에 동의한다. (나는 포인터에 대해'typedef'-s처럼'xmlNodePtr'을 싫어한다.) 그리고 GTk는 그것을 사용하지 않습니다. (GCC 내부가 typedef'tree '를 가지고 있고 복잡한 데이터 타입을 가리키는 또 다른 typedef'gimple'이 있더라도). –
이러한 종류의 typedef는 특별히 유용하지 않습니다. 그러나 포인터 typedef가 실제로 유용한 한 가지 경우는 함수 포인터를위한 것입니다. 왜냐하면 원시 함수 포인터 구문이보기에 지저분하기 때문입니다. – TJD
FWIW, 여기에 리눅스 커널 개발자의 의견과 함께 몇 가지 근거가 있습니다 : http://www.kernel.org/doc/Documentation/CodingStyle –