Windows SDK features IsEqualGUID() function and operator==() for two GUIDs that return BOOL (equivalent to int):
// Guiddef.h
#ifdef __cplusplus
__inline int IsEqualGUID(REFGUID rguid1, REFGUID rguid2)
{
return !memcmp(&rguid1, &rguid2, sizeof(GUID));
}
#else // ! __cplusplus
#define IsEqualGUID(rguid1, rguid2) (!memcmp(rguid1, rguid2, sizeof(GUID)))
#endif
//also in Guiidef.h
#ifdef __cplusplus
__inline int operator==(REFGUID guidOne, REFGUID guidOther)
{
return IsEqualGUID(guidOne,guidOther);
}
#endif
What’s the point in that int? I understand that C doesn’t have bool datatype, but there’s an #ifdef __cplusplus around, so this code will only be compiled as C++, so bool will be supported anyway. Having a negation near memcmp() effectively transforms all possible values returned from memcmp() into zero and nonzero.
Also there’re no user-defined operators in C – only C++ supports them. So the operator== would not compile in C code anyway.
Are there any reasons for choosing int instead of bool here?
Because the Windows API exposes
IsEqualGUID()as a function returning aBOOL. They need to keep a stable interface.BOOLandboolare different sizes, and the Windows API is designed to be compatible with a variety of languages and compilers. Remember that there are other languages other than C++ that interact with the Windows API.On C and C++,
IsEqualGUID()is implemented in terms ofmemcmp(), butIsEqualGUID()is also implemented inole32.dll. You can obtain the function fromole32.dll:So even though it’s implemented as an inline function in C++, other languages may use the DLL implementation of
IsEqualGUID(). The C++ version returns aBOOLso it is consistent with the API.