Open
Conversation
Signed-off-by: Isaev, Ilya <ilya.isaev@intel.com>
isaevil
requested review from
akukanov,
aleksei-fedotov,
dnmokhov,
kboyarinov and
vossmjp
vossmjp
reviewed
Apr 2, 2026
| The proposed approach has several advantages over other alternatives: | ||
|
|
||
| - It does not require the modification of existing headers, as the module includes them as | ||
| part of global module fragment and then selectively export the necessary `using` |
Contributor
There was a problem hiding this comment.
Suggested change
| part of global module fragment and then selectively export the necessary `using` | |
| part of a global module fragment and then selectively exports the necessary `using` |
vossmjp
reviewed
Apr 2, 2026
|
|
||
| - It does not require the modification of existing headers, as the module includes them as | ||
| part of global module fragment and then selectively export the necessary `using` | ||
| declarations. Thus, the development can continue in headers. |
Contributor
There was a problem hiding this comment.
Suggested change
| declarations. Thus, the development can continue in headers. | |
| declarations. Thus, development can continue in headers. |
vossmjp
reviewed
Apr 2, 2026
| - It does not require the modification of existing headers, as the module includes them as | ||
| part of global module fragment and then selectively export the necessary `using` | ||
| declarations. Thus, the development can continue in headers. | ||
| - Since the API is declared as part of global module fragment, the name of the module will |
Contributor
There was a problem hiding this comment.
Suggested change
| - Since the API is declared as part of global module fragment, the name of the module will | |
| - Since the API is declared as part of a global module fragment, the name of the module will |
vossmjp
reviewed
Apr 2, 2026
| part of global module fragment and then selectively export the necessary `using` | ||
| declarations. Thus, the development can continue in headers. | ||
| - Since the API is declared as part of global module fragment, the name of the module will | ||
| not participate in the name mangling, making translation units compiled with modules, |
Contributor
There was a problem hiding this comment.
Suggested change
| not participate in the name mangling, making translation units compiled with modules, | |
| not participate in name mangling, making translation units compiled with modules, |
vossmjp
reviewed
Apr 2, 2026
| not participate in the name mangling, making translation units compiled with modules, | ||
| compatible with the units compiled with regular headers. | ||
|
|
||
| The disadvantage of this approach is an obligation to update the module interface unit each time new API is added. |
Contributor
There was a problem hiding this comment.
Suggested change
| The disadvantage of this approach is an obligation to update the module interface unit each time new API is added. | |
| The disadvantage of this approach is an obligation to update the module interface unit each time a new API is added. |
vossmjp
reviewed
Apr 2, 2026
|
|
||
| ### CMake integration | ||
|
|
||
| The library must remain at C++11 as the minimum standard, hence the module source cannot be |
Contributor
There was a problem hiding this comment.
"must remain at C++11" is because of a project policy, not a technical reason. We may for example later, change to C++17 as the minimum standard as a policy change. As written, its unclear if you are stating a design constraint or a technical constraint.
vossmjp
reviewed
Apr 2, 2026
|
|
||
| The library must remain at C++11 as the minimum standard, hence the module source cannot be | ||
| compiled as part of the oneTBB build. Additionally, currently the built module constrains | ||
| the consumer to use the specific version of the C++ standard: the one that was used during |
Contributor
There was a problem hiding this comment.
Suggested change
| the consumer to use the specific version of the C++ standard: the one that was used during | |
| the consumer to use a specific version of the C++ standard: the one that was used during |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Add a comprehensive description of proposed changes
Fixes # - issue number(s) if exists
Type of change
Choose one or multiple, leave empty if none of the other choices apply
Add a respective label(s) to PR if you have permissions
Tests
Documentation
Breaks backward compatibility
Notify the following users
List users with
@to send notificationsOther information