KhronosGroup / KhronosGroup/OpenCL-CLHPP
add a preprocessor enable for provisional extensions or features
- Dominant language
- C++
- Stars
- 425
- Forks
- 133
- Avg merge
- 3h 30m
- Merged PRs (30d)
- 1
Description
I've been generally trying to reduce the number of special `CL_HPP_FOO` preprocessor defines in these C++ headers, but I think it would be good to add a preprocessor define to explicitly opt-in to provisional extensions or features. This will avoid breaking code that doesn't use these features if their definitions change as part of the provisional review process, say by removing or renaming functions or enumerants.
Assuming we want to do this, the hardest thing will probably be deciding on a name. Some options:
* `CL_HPP_ENABLE_PROVISIONAL_FEATURES`
* `CL_HPP_ENABLE_EXPERIMENTAL_FEATURES`
* `CL_HPP_USE_PROVISIONAL_FEATURES`
There are already several defines to `ENABLE` or `USE` features, such as `CL_HPP_ENABLE_EXCEPTIONS` and `CL_HPP_USE_CL_SUB_GROUPS_KHR`, so although I have a slight preference for `ENABLE` I think we could go either way.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the OpenCL-CLHPP C++ headers and review existing CL_HPP_ENABLE_* and CL_HPP_USE_* defines, including CL_HPP_ENABLE_EXCEPTIONS and CL_HPP_USE_CL_SUB_GROUPS_KHR. Decide the opt-in define name and scope for provisional extensions or features; done means those definitions are excluded unless explicitly enabled, avoiding changes for users who do not use them.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100