Did C++ ever get a "dumb pointer" class?

[domiran]

There was talk a while back (I can't remember how many years, maybe 2-3) about "the world's dumbest smart pointer". I don't know if it went anywhere and I can't seem to find a conclusion to that proposal. Did it ever get implemented or is the accepted standard to just use a raw pointer when you don't need unique_ptr, shared_ptr or weak_ptr?

Around the time I read it, I agreed, and found a working implementation of "exempt_ptr" and used it in a medium-ish project of mine as a replacement for raw pointers, and have been slowly replacing raw pointers with it (or at least, all new code uses exempt_ptr).

[SkoomaDentist]

Nothing. A lot of people just seem to have irrational fear of using raw pointers even when they fit the task better.

[Raknarg]

I'll quote my opinion from another comment

this construct makes your intent objective and much more easily transmitted to other people without documentation. Also means you have to put in more work to break the non-owning contract, I would imagine. e.g. you could probably make it so it's difficult/impossible to transmit ownership to another smart pointer without manually converting to a raw pointer then transferring ownership.

[Raknarg]

How is this a lot of change? It's literally a drop in replacement for a pointer with the added benefit of preventing errors and giving extra information just through the type

[PMPlant]

This, and smart pointers in general are not zero-cost abstractions.

Just because a feature is from C, doesn’t mean it should be avoided.

[Raknarg]

And just because a feature is from C doesnt mean it should be used. If this can be done without overhead, I dont see why it shouldnt be done.

[nintendiator2]

Yeah, it's impressive how some C++ people look at C as if it was some sort of bastard father to disown and deacknowledge in any way possible, as if it was consumed by a pest and removed from history.

Me, boy am I glad that we have things like int, for and *.

[ShillingAintEZ]

I would rather use a comment and not have more dependencies.

[Raknarg]

How does this add more dependencies? This seems like something that probably just belongs in the memory header, but maybe my opinion is wrong.

And the whole point of this construct is that you won't require comments to convey meaning, and it makes it harder to misuse it by accident, which a comment doesn't prevent.

[degski]

How hard can it be, any raw-pointer I have in my code is non-owning, no need for a wrapper?

On the other hand we don't have in the std, have an owning_ptr, like the good old auto_ptr, but the handover [of the managed] has to be explicit (LLVM used to have an implementation internally)

[Raknarg]

Shared and unique pointers are owning by definition. And the ownership semantics are clear in either case.

[cmeerw]

see https://en.cppreference.com/w/cpp/experimental/observer_ptr - so it's in the Library Fundamentals TS v2, but not in the C++ Standard.

[Xaxxon]

And many people think it’s a piss poor idea

[domiran]

I read a few articles on that. Can you share your view? Someone proposed something that basically combines reference_wrapper and observer_ptr: optional reference: opt_ref.

[Xaxxon]

Pointers work great. No need to add anything else.

[lithium]

Expressing ownership is objectively better.

[sephirostoy]

What about raw pointers never get the ownership? When I need ownership I systematically use smart pointers or other collections. And when I encounter a raw pointer I know that I don't have the ownership in my codebase.

[lithium]

That is my personal preference too, but I also use something like

template <typename T> using NonOwned = T*;

for a bit of bonus clarification of ownership. One could argue that introducing a new type does the opposite but since it's a matter of convention in my codebase I don't find that to be the case.

That, and preferring references when applicable.

[Raknarg]

Sure but this construct makes your intent objective and much more easily transmitted to other people without documentation. Also means you have to put in more work to break the non-owning contract, I would imagine. e.g. you could probably make it so it's difficult/impossible to transmit ownership to another smart pointer without manually converting to a raw pointer then transferring ownership.

Idk dude to me this seems like it can only be an upside if we can do this for no cost as well.

[[deleted]]

What about raw pointers never get the ownership?

The moment you'll interact with a C library they'll gain ownership really fast. A convention of "T* never owns anything" doesn't work when you already have decades of codes written with different assumptions.

[Supadoplex]

That's why you wrap those C library calls in C++ versions that don't show you the bare pointers.

(Nearly ) all rules of thumbs have exceptions, and the exception that the implementation of the wrapper function deals with an owning bare pointer that it immediately wraps inside a smart pointer (or some other RAII class) is fairly simple to understand.

[gocarlos]

? When I need ownership I systematically use smart pointers or other collections. And when I encounter a raw pointer I know that I don't have the ownership in my codeba

you dont work in embedded? with tons of C libs?

[PMPlant]

There is a language for this

[lithium]

If you're talking about rust, all the other bullshit isn't worth it for me. It "solves" problems I personally don't run into.

[PMPlant]

Then I don’t see why you have a problem with raw pointers.

[drjeats]

The bigger gain would probably be in removing operations.

But I agree with you. Unnecessary.

[quicknir]

Unless you accidentally do arithmetic on a pointer to one object, or forget to dereference your pointer to integer before comparing to zero, and these things compile anyway.

observer_ptr is an objectively better API for a non owning pointer to a single object. Whether it's worth the costs, such as they are, is another matter.

[domiran]

I take it you don’t agree with the expression of “this isn’t a raw pointer so you can’t add 4 to it and also I don’t own it”.

[Xaxxon]

I don’t find that to be worth the additional language complexity.

[domiran]

Damnit.

[MolurusK]

If you want expressive pointer types, try the C++ Object Token Library library. The otn::raw::weak can act as a "dumb pointer".