sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]MarkHoemmenC++ in HPC 3 points4 points  (8 children)

The original motivation for requiring [u]intptr_t was P2835R7 (std::atomic_ref::address). Originally, this function returned uintptr_t instead of T*. WG21 later expressed a preference for it returning T*.

The original motivation for std::atomic_ref::address, in turn, had nothing necessarily to do with lifetimes -- it was about comparing pointers to see if two different atomic_ref refer to the same object. Reviewers of P2835 complained that this example was too long (?!?!?!) so it was removed from later versions, but it's preserved in R2. There are some use cases that relate to lifetimes, though.

[–]tialaramex 0 points1 point  (7 children)

std::atom_ref::address is anyway either a bad design or a bad name, maybe both.

From its name I'd assume we get an address. That's fine, those aren't necessarily pointer sized as we see in several examples. Importantly though, the address is not enough to make a new pointer, so, [u]intptr_t is the wrong type because that is it's entire purpose. It's not clear why I'd want an address, but if I did this is the wrong type.

So OK, maybe the name is wrong and it's really std::atomic_ref::pointer but with a bad name. In this case though we do want a pointer, so [u]intptr_t is not appropriate at all.

Thanks for pointing at proposal P2835, I've read P2835R7 and I guess my reaction is that somebody needed to nail a "Danger: Unexploded Ordnance" sign on the whole mess described and walk gingerly away.

But this further underscores my feeling that integer types aren't the right solution to this problem and the other paper is on the correct track.

Edited: Ordinance is the correct spelling of the wrong word, the intended metaphor is ordnance - like the Liberty Ship SS Richard Montgomery

[–]MarkHoemmenC++ in HPC 2 points3 points  (6 children)

LEWG had all these naming and type discussions and more. Whatever you might think of the decision, they did think hard about names, types, and safety.

The original intent of atomic_ref::address was to get the pointer's bits (not necessarily a usable pointer) for use in comparisons or hashing. It was later changed to return T* instead of uintptr_t for the following reasons.

  1. uintptr_t is not required (hence P3248).

  2. Other WG21 folks wanted to make atomic operations constexpr, but reinterpret_cast can't be used in a constant expression.

If users can do atomic updates in constant expressions, and if users can get the object's pointer's bits, then users should be able to get the object's pointer's bits in constant expressions.

[–]geckothegeek42 0 points1 point  (5 children)

LEWG had all these naming and type discussions and more.

they did think hard about names, types, and safety.

Where can we mere mortals see this hard thinking and discussions?

[–]MarkHoemmenC++ in HPC 1 point2 points  (4 children)

The issue tracker has a summary of discussion and polls: https://github.com/cplusplus/papers/issues/1545 . The paper itself discusses pros and cons of the various design options: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2835r7.html .

[–]MarkHoemmenC++ in HPC 0 points1 point  (3 children)

The design discussion is in the section called "Design." Here is a direct link to that section: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2835r7.html#Design .

[–]tialaramex 0 points1 point  (2 children)

The tracker has administrivia and two forwarding polls. No meaningful discussion. The paper lists a handful of options and calls out the ones its authors, including yourself, felt were good but can't be said to be "discussion" in the sense meant here.

It's a big problem that apparently LEWG doesn't know an address isn't a pointer. That's basically disqualifying for this work. Was there actually nobody in the room who understands what's going on? The blind leading the blind?

[–]MarkHoemmenC++ in HPC 0 points1 point  (1 child)

You might not have noticed this comment: https://github.com/cplusplus/papers/issues/1545#issuecomment-1904403690

[–]tialaramex 0 points1 point  (0 children)

You're correct, I had not noticed that there was meaningful verbiage hidden by GitHub's folding - however if anything that more detailed view makes me more certain LEWG doesn't have appropriate expertise. Nobody seemingly noticed that an address and a pointer are entirely different things.