KhronosGroup / KhronosGroup/OpenCL-CLHPP

add a preprocessor enable for provisional extensions or features

Open
#272 0 comments 0 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.