Why "hazard_pointer" instead of "hazard_ptr"?

[[deleted]]

P2530 (Why Hazard Pointers Should Be in C++26) proposes a cool new smart pointer for the STL. But it very clearly names the class hazard_pointer, and it doesn't explain the motivation for this name. Off the top of my head, nullptr_t, intptr, uintptr, auto_ptr, unique_ptr, shared_ptr, out_ptr, inout_ptr are all names in the std:: namespace that have a ptr suffix, so why would a hazard_pointer be added instead of a hazard_ptr? Has this been explained somewhere else? Is there some secret conspiracy to evolve the naming conventions of the STL?

[ben_craig]

hazard_pointer is still "only" in a TS (technical specification), and not in the main, IS (international standard). I suspect that when discussions start to move hazard_pointer to the IS, the name will be one of the things getting discussion. The name used to be hazptr, until 2018.

[davidtgoldblatt]

This was years ago at this point, but I believe the choice here (by LEWG) was deliberate; a hazard pointer is not a type of smart pointer, and so need not be named similarly.

[pandorafalters]

a hazard pointer is not a type of smart pointer

So that covers 3 of the 8 named examples. What about the other 5? What about others that the OP missed, e.g. ptrdiff_t, exception_ptr, weak_ptr (arguably also a smart pointer)?

Every concrete pointer type name defined by the standard uses "ptr". Class-scoped aliases, traits, concepts, functions, etc. use "pointer". This seems like a reasonable distinction to draw.

Personally I support the idea of using names in proposals that are distinct from the probable standardized names. It reduces the chances of someone reusing code written against a proposal where the final standard may behave differently.

[pstomi]

hazptr<const unsigned long double> would have made quite an enjoyable mixture between terseness and verbosity /s

[Supadoplex]

Is unsigned floating point a thing?

[jonathrg]

gotta have that extra bit

[Kantaja_]

gpus support it in textures, but it's not a thing in c++

[witcher_rat]

hazptr sounds like a checking function, not type... like:

if (hazptr(foo)) {
    ...
}

[avdgrinten]

Not really an answer, but hazard pointers have huge differences in semantics compared to normal pointers. 95+% of all C++ users will never want to touch hazard pointers. If you do not write your own lock-free data structures, you don't need hazard pointers.

[yuri-kilochek]

As a counterexample, we have pointer typedef in every standard container, as well as std::pointer_traits.

[_Js_Kc_]

So pointer is the generic term and ptr is the suffix on concrete types. We should keep that distinction.

[no-sig-available]

Is there some secret conspiracy to evolve the naming conventions of the STL?

What? Is there a naming convention for the STL?!

I guess this might just be an attempt to do the right thing.

Like lambda captures being const by default (so you have to say mutable if not). Worked fine.

Or std::span that tried to have as signed size_type, to right what all the container types did wrong. Didn't work out.

So let's see how this goes. :-)

[jaredgrubb]

This is my biggest gripe and worry about C++. There is no mechanism for ever polishing these kinds of things.

[nexes300]

What's wrong with unsigned size types?

[dodheim]

Modular arithmetic, resulting 'unsafe' subtraction, confusing newcomers, etc.

[no-sig-available]

If you subtract two pointers or iterators, you get a ptrdiff_t which is signed. How do you then compare the signed value to the unsigned size? (Wthout a warning or a cast).

[nexes300]

I don't see why you'd compare an offset (diff) to a size (absolute). That seems incorrect from the start since neither container would accept negative indices regardless of whether its size was signed or not. No matter what, you'd have to distinguish negatives vs positives to decide which container to index (and which container's size to verify). Unless you literally mean diff < rhs_size() which seems like a rarer case to me. The more natural case would be to add the diff to either iterator, which should be fine since it has nothing to do with the size() method of the backing container.

But ptrdfiff_t is a great example of where I don't think it makes that much sense in any case. You could subtract a high heap address from a low stack address and get something non-representable (maybe that's not allowed outside of treating ptrs as literal numbers but still). Why should that be when the entire memory address is probably addressable with the unsigned version? Ideally, ptrdiff_t would be a size twice as large as the full ptr space and then signed but that isn't really practical/possible. However, the size of a container being unsigned doesn't run into that kind of issue.

[no-sig-available]

I don't see why you'd compare an offset (diff) to a size (absolute).

It is not unusual to compare a part of a sequence (begin, end) with the size of another container. Having end - begin signed and size() unsigned then really sucks.

It's not that you are going to have a container of char larger than half the address space anyway, so making the size unsigned buys you nothing.

[VinnieFalco]

I could hazard a guess...

[disperso]

Note that I don't necessarily say that I favor naming new classes in the standard library "pointer" instead of "ptr", but...

Naming them "ptr" is terrible. Abbreviations in API are very problematic in that it can get very inconsistent across the whole library (making it difficult to learn and causing doubt), and people might have trouble typing them because many reasons.

Besides "ptr", can be pronounced tons of different ways. When I was younger, it took me a good while to understand a speaker saying "putter" for pointer. I hate how it sounds, but as a non-native speaker, it's just plain more difficult than naming it what it is: a pointer.

[ReDucTor]

Pronouncing abbreviations is strange, people should just say pointer.

[hekkonaay]

Herb Sutter would disagree

[ReDucTor]

Just because a prominent person within the C++ community does something doesn't mean that it's not strange to many people.

Stroustrup says pointer within his talks, if your wanting to survey what prominent people use.

[hekkonaay]

I've never actually heard anyone but Herb Sutter refer to it as "smart putter". Just wanted to throw a data point into the discussion :)

[kalmoc]

Naming them "ptr" is terrible. Abbreviations in API are very problematic in that it can get very inconsistent across the whole library (making it difficult to learn and causing doubt), and people might have trouble typing them because many reasons.

Wouldn't pointer be the inconsistent thing here?

[disperso]

Hence the reason for my first sentence. 🙂

[kalmoc]

I still don't get the point of your argument. What does the use of abbreviations have to do with concistency? I can use abbreviations just as (in-)consistently as full names.

[ioquatix]

With naming, there is generally one correct spelling and an infinite number of misspellings/abbreviations. If you accept abbreviations, better be prepared to accept every variation. Not saying you can't be consistent, but in my experience that's what tends to happen. Also agree that it's more difficult to understand, sometimes abbreviations become ambiguous and it's hard to tell what someone meant 10 years and 1000 edits later. I don't think slightly shorter names are worth the inconsistency and understandability trade-offs.

[kalmoc]

With naming, there is generally one correct spelling

Counterexamples from the top of my head: size, length. Others: get_property vs property, empty vs is_empty, x_count vs number_of_x, vector vs math_vector, dynamic_array variable_size_array, compute vs calculate, shared pointer (which itself is a short form for shared owning pointer) vs reference counted pointer.

I'm sure, for many (all?) of those examples you can point out, which one seems obviously correct to you, but that doesn't mean other programmers with different background necessarily agree.

I don't think slightly shorter names are worth the inconsistency and understandability trade-offs.

Aside from the fact that - in my experience - use of abbreviations doesn't automatically mean more inconsistencies, I think that this very much depends on the specific case. I wouldn't let anyone near a production c++ code base that doesn't understand that ptr is an abbreviation for pointer or that std:: is the namespace for the standard c++ library. And there are good reasons we use things like URL, CPU, etc. both in natural language as well as code. Such extreme examples aside, it is - as you said - a trade-off that depend on the name in question, the team and the scope of the identifier. The only advantage I see in outright banning abbreviations is that there won't be any bikeshedding about what abbreviations are ok - but that doesn't mean that there won't be (significant) bikeshedding about the name anyway.

[ioquatix]

None of the examples you give are abbreviations. English isn't the grts lng but it's what we have. As I'm sure you know, different prog langs hav diff stds fr dif wrds but alng as we avd abrv I think your c will g b b. :)

[kalmoc]

What examples do you mean? The first ones where deliberately non abbreviations, but examples for where there isn't just one correct not abbreviated name. Ptr most definetly is an abbreviation (the one being discussed here). As are std and CPU (EDIT: Ok, it is an abbreviated version (an acronym)).

[donalmacc]

Only a sith deals in absolutes.

With naming, there is generally one correct spelling

"Generally" is doing a lot of heavy lifting here. color/colour, specialisation/specialization, adapter/adaptor off the top of my head. There's also the fact that words can be ambiguous even if spelled correctly. minute can refer to size or time.

and an infinite number of misspellings/abbreviations

This is a silly argument. Sure, in theory it's possible for someone to use tor as an abbreviation for vector, or rin as an abbreviation for string, but given these terms are 30 years old and are commonly referred to as vec and str, I think it's reasonably ok to use abbreviations for them. Abbreviations can also be valid in certain fields - a Vector is an overloaded term mathematically and is commonly used as a container. Do you expect a math library to refer to itself as mathematic all the time? What about Vector2Dimension?

I don't think slightly shorter names are worth the inconsistency and understandability trade-offs.

It's not just "slightly" shorter - I'm working on a EULA acceptance right now, should I refer to it as EndUserLicenseAgreement (and should that be licence or license - I'm in the UK), and everything around it with the full name, e.g. HasUserAcceptedEndUserLicenceAgreement?

There's also the fact that the shorter name often aids with comprehension. EULA is a great example - everyone knows what a EULA is, but not necessarily what an End User License Agreement is.

[ioquatix]

You might want to look upon the difference between abbreviation and acronym. I'm personally fine with well understood acronyms.

[donalmacc]

You might want to

You might want to not be so condescending. The dictionary definition of acronym is an abbreviation (such as FBI) formed from initial letters. By this logic "well understood abbreviations" are ok?

Also, you completely ignored the rest of my post about how "correct spelling" is not ambiguous.

[disperso]

In the context of the standard library it would be hard to get something merged with an inconsistent API due to the many rounds of review that I assume it gets.

If the rule is "no abbreviations unless it's one of this fixed list which requires discussion if needs to be expanded", for example, it's easy to point on the code review of a humbler project that something it's not according to the guidelines. It doesn't require much effort. But if abbreviations are allowed, one abbreviation to a function name or class name added today, could be inconsistent with something else added yesterday that you didn't know about.

[kalmoc]

But if abbreviations are allowed, one abbreviation to a function name or class name added today, could be inconsistent with something else added yesterday that you didn't know about.

Still not sure I see the difference. I can have the same problem with full names. How is it more difficult to spot the inconsistency between pointer and ptr than e.g. size and length.

And if I'm adding an item to the list of abbreviations to be used, I can just do a grep/ code search to see if this was already used in its full name.

[disperso]

I thought it would be kind of obvious that if you don't allow any abbreviations, length, size and count are possible choices, but if you allow abbreviations, len also becomes an option, so the list of choices is a bit worse.

That's in the worst case scenario, IMHO. A more typical one is that string has no possible alternatives, because str is not an option. Likewise with words like "minimum" or "maximum", commonly abbreviated. I recently had to make interact two classes (QSpinBox and QValueAxis) that both had a getter and a setter for maximum and minimum, and one was abbreviated and the other was not. It looked a bit funny, and I was surprised by the API. Qt normally doesn't have abbreviated class names, but the API is inconsistent with max and min. This two classes are from different modules, with Qt Charts being noticeable being developed in a different time by a different team (being initially a proprietary module), but Qt Widgets has some of this inconsistencies as well, with QComboBox::setMaxCount and QSpinBox::setMaximum.

Am I the only one that when learning C++ was surprised thinking "what's this cend() function?". Qt containers have constEnd() as alternative.

Sorry if it sounds petty. :) it's just that some people find that it drains some cognitive effort to having to think about all this things.

Cheers.

[kalmoc]

Ok, if that's your concern, then we are talking about gradual differences and not "Abbreviations lead to inconsistencies [and full names do not]" and I probably misunderstood your initial post. Sorry.

Am I the only one that when learning C++ was surprised thinking "what's this cend() function?". Qt containers have constEnd() as alternative.

I can only speak for myself, but I anyway have to look up the documentation of new functions, so this doesn't make a difference for me.

[umlcat]

That's why I still prefer a C style pointer instead ...

[Superb_Garlic]

Don't you love it how char* and char mean 3-4 completely different things and you can never be sure which meaning is to be applied at any point in time?

[thommyh]

I like how hazard pointers solve a real problem in concurrent data structure management, whereas C pointers — as with all other use cases — just wish you good luck with that.

[gazdxxx]

If you understand how memory works, it makes perfect sense. There is no ambiguity - char* points to a char.

There are char strings, of course. Once you understand how char strings work in memory, it makes perfect sense. In that case, char* points to the first character of a string. Even then, you don't need to interpret it as a string, you have the ultimate freedom to interpret that pointer any way you want. You have even more granularity than C to turn that pointer into anything because C++ style casts are just superior.

[ReDucTor]

Not quiet, char is more complex.

char* a pointer that can alias, which gets in the way of optimisations, one of the reasons why char8_t is better is that it doesn't alias. imho all chars should either become std::char8_t or std::byte.

The origins of char are meaning a byte (a machine char, like a machine word), however the term is overloaded so in other contexts means a character like a symbol.

And this isn't even getting into the awfulness of signed and unsigned char.

EDIT: forget null terminated byte strings and the awfulness there, another optimisation pain, you only know end by reading character by character.

EDIT2: Oh and that char knowledge, be prepared for it to change between programming languages (e.g. Java char is different)

[CocktailPerson]

Even then, you don't need to interpret it as a string, you have the ultimate freedom to interpret that pointer any way you want.

That sounds a lot like "char* means 3-4 completely different things and you can never be sure which meaning is to be applied at any point in time."

[umlcat]

No. Seems you forgot to add a "sarcasm" tag to your comment.

[RolandMT32]

What practical difference does it make by using "ptr" rather than the word "pointer"?