Reputation: 167
I am studying Import Export Extension of Khronos openvx. while reading vx_import.h
file I saw
VX_API_ENTRY vx_status VX_API_CALL vxReleaseImport(vx_import *import);
function.
I want to understand why they have written VX_API_ENTRY
and VX_API_CALL
in the function.
I am new to openvx. If anyone knows this please reply.
Upvotes: 0
Views: 133
Reputation: 98358
In the vx_types.h
header you can read:
/*!
* \internal
* \def VX_API_ENTRY
* \brief This is a tag used to identify exported, public API functions as
* distinct from internal functions, helpers, and other non-public interfaces.
* It can optionally be defined in the make system according the the compiler and intent.
* \ingroup group_basic_features
*/
/*!
* \def VX_API_CALL
* \brief Defines calling convention for OpenVX API.
* \ingroup group_basic_features
*/
/*!
* \def VX_CALLBACK
* \brief Defines calling convention for user callbacks.
* \ingroup group_basic_features
*/
Then, VX_API_ENTRY
is defined as empty and VX_API_CALL
is defined __stdcall
on Windows, and empty otherwise.
What are they for? Well, those are specifying the calling convention of the API, and at the same time, as the comment says, documenting which functions are actually public.
For example, in Windows, public functions from a DLL sometimes have declspec(__dllimport)
prefixed to instruct the compiler to use the import function table, your build system can define VX_API_ENTRY
for that.
The __stdcall
thing is the calling convention used by this library. Usually you do not specify it and let the compiler choose the default. But in a public DLL it is a good idea not to rely to much on defaults, because the DLL compiler and the EXE compiler may use different values, and that would break the linking.
But mostly, as an end-user of the API you can just ignore them, they just work.
Except for VX_CALLBACK
! You must declare your callbacks as VX_CALLBACK
or you risk your code failing on some architectures (mainly Windows).
Upvotes: 1