Open sleeepyjack opened 2 months ago
As discussed offline, the proposal is still in-flight and not plenary approved. However, it was forwarded by LEWG to electronic polling so they are happy with the current design and it may have settled.
Please notice that you are linking to revision 2 of the proposal, which proposes:
T const* data() const noexcept;
The latest proposal, revision 4, proposes the following API:
uintptr_t address() const noexcept; // optional
I am fine with adding the functionality from revision 4, but would like to have a second opinion. @wmaxey I think you have been working on atomics lately? What do you think?
Is this a duplicate?
Area
libcu++
Is your feature request related to a problem? Please describe.
I just found @gonzalobg ’s proposal for exposing
std::atomic_ref<T>.data()
to access the underlying memory location wrapped by the atomic_ref object when running into a similar use case as the one shown in the proposal.Describe the solution you'd like
I know standardization might take years, but since we own the
cuda::
namespace, would it be possible to expose this for device atomics in libcu++? IIUC it would be an extension to the standard API and would not affect the current behavior.There have been some discussions and proposed changes on how to expose the address and the committee hasn't ultimately settled on a design. We could however expose it with an experimental name for now.
Describe alternatives you've considered
There's currently no way (to my knowledge) to obtain the address of the object wrapped by an
atomic_ref
object.Additional context
No response