Add support for CL_HPP_OPENCL_API_WRAPPER macro #314
Conversation
include/CL/opencl.hpp
Outdated
| #define _CL(name) ::name | ||
| #define _CL_PTR(name) &::name |
There was a problem hiding this comment.
Do we need both _CL and _CL_PTR? I can't figure out why _CL_PTR is needed, and it seems like we could use _CL in all cases.
If we do need _CL_PTR for some reason, should there be a separate wrapper macro for it as well? I'd prefer not to do this, and would much rather eliminate _CL_PTR, but we should stay symmetric regardless.
One final nit: identifiers beginning with an underscore and a capital letter are considered reserved IIRC, so although I appreciate the brevity we should use a different spelling than _CL.
There was a problem hiding this comment.
For some reason I was thinking that a & is needed when taking a function pointer, but I think that's only the case for pointer-to-members, not for normal function pointers, so using _CL everywhere should work fine, yes.
Also, I'll rename _CL to CL_ which is not reserved.
There was a problem hiding this comment.
Ok, I've updated the PR.
Add support for a macro CL_HPP_OPENCL_API_WRAPPER which will be used to wrap all OpenCL API calls.This can be used e.g. to load the OpenCL library dynamically with dlopen()/dlsym().
steffen-kiess
force-pushed
the
api-wrapper-macro
branch
from
27ee061 to
b7d7f90
Compare
Add support for a macro
CL_HPP_OPENCL_API_WRAPPERwhich will be used to wrap all OpenCL API calls.This can be used e.g. to load the OpenCL library dynamically withdlopen()/dlsym().This is similar to #170, but uses a macro which is called with the API function name instead of a namespace. This macro can e.g. call a function which will open the OpenCL library if needed, look up the function name and return a pointer to API function.