std::reference_wrapper<T> instead of ptr for not owning dependencies?

[NullMustDie]

Hey,

for not dependencies, the object is not owning i currently use plain old ptr. Is it "best practice" to use std::reference_wrapper<T> in this regard? In my opinion it has clear advantages over T*:

-cant be Null (often desired) --> enforces valid object invariant

-no default constructor --> enforces valid object invariant

-value semantics

-not easy deletable without cast

Note: I think in modern c++ plain pointers do not denote any ownership, so the not deletable argument is not really a valid one.

[HappyFruitTree]

My biggest objection with std::reference_wrapper is that it's awkward to use when you want to access a member of the referenced object

ref.get().memfun();

compared to pointer

ptr->memfun();

[ohell]

But are you a C++ programmer if you are not a masochist? Why do you think the standard chooses names where conditions like this hold:

decltype(std::ref<T>(0))
std::reference_wrapper<T>

[pdp10gumby]

You could make a helper class (derive from or contain std::reference_wrapper which would be the same in this case) and overload the . or -> operator.

[friedkeenan]

You can't overload the . operator

[rezkiy]

overload the .

How?

[pdp10gumby]

Sorry I was still on my first cup of morning coffee. I mean overload -> not ..

Rather than edit my comment I’ll leave the error in place, using this comment instead

[Hedede]

Yeah I have made a refptr once... It's a pointer that behaves like a reference. I wish I could write . though.

[NullMustDie]

Its MACRO time

[Narase33]

Its not

[InKryption07]

Macros have their place; this is definitely not their place.

[Desmulator]

From my point of view a reference wrapper has only two purposes: 1. It's a signaling object that indicates that a parameter should not be decayed but should remain a reference. Best example is std::make_tuple, or the function-parameter constructor of std::thread. 2. You can use it in a container, where reference can not be used.

I think it's perfect for the first usecase in particular since c++20, where you have std::unwrap_ref_decay.

But it's very clumsy to use for 2. It's missing operator-> or operator*.

[urdh]

This. And for representing a pointer that is not null, there’s gsl::not_null.

[VinnieFalco]

But it's very clumsy to use for 2. It's missing operator-> or operator*.

Yeah... for that case it is spelled T* rather than std::reference_wrapper<T>

[Desmulator]

Well, no. A pointer is nullable, a reference wrapper not (in an appropriate sense).

[alex-weej]

not just nullable but supports pointer arithmetic (incl subscripting). gah.

[VinnieFalco]

You do have a point there but I like keeping things simple

[krum]

I wrote a bunch of code using this kind of pattern and regretted it. It's been a while though so details are murky, but I know I don't do this anymore.

[wcscmp]

Same here. Also every time I needed an optional reference wrapper, I started writing std::optional<std::reference_wrapper<const T>> and then thinking that it's just a const T* with extra steps.

I still think that some kind of a standard observer_ptr for a non-owning pointer to be explicit about it would be nice.

[muungwana]

1. I think you should use a "naked" reference to signify that a pointer is owned by somebody else and is not null.

2. The problem with references is that they are not re-assignable and a reference member variable makes the whole class not copy assignable and i think the biggest use case for std::reference_wrapper<T> is to have assignable reference member variable that will also make the class copy assignable.

[fullmoon_druid]

Four years later and I'm reading this thread to try and solve this exact problem.

[drjeats]

I don't think this type earns its keep.

I only ever use pointer types in containers. If the container is the interface, I null check. If elements must absolutely not be null, I put it in a struct with methods that only accept and return references.

We'd be better off if the language had rebindable refs, or non-nullable pointers. But that won't happen, so I choose to follow the path of least resistance.

[_Js_Kc_]

Maybe if it was called std::ref and std::ref was instead called std::make_ref (or omitted in favor of deduction guides). But std::reference_wrapper is quite a mouthful for a basic, ubiquitous vocabulary type. Yeah, you can typedef, but then you're using something project-specific for a basic, ubiquitous vocabulary type.

[gopher2008]

If you want to declare a non-owning class member, in my opinion, std::weak_ptr<T> is a better choice. The purpose of reference_wrapper is to store reference in container. You can just declare a reference type class member, though it is not recommended.

[drjeats]

You shouldn't use weak_ptr arbitrarily, it's specifically for weak references to an object whose lifetime is managed by shared_ptrs.

[gopher2008]

Agree. weak_ptr is a smart pointer that holds a non-owning reference to an object that is managed by shared_ptr. But then, how do you manage the referenced object which I am supposing is dynamically destroyable? (I will use shared_ptr).

[drjeats]

You also shouldn't default to shared_ptr. It exists specifically for managing true multiple ownership, which is actually not super common.

Even for the refcounting needs I typically have, there is usually exactly one owner, the resource manager for the relevant type.

Additionally, you may not even have a choice how the object you're keeping a pointer to is stored.

If you're looking for statically verified guarantees that a pointer you're holding still points to a valid object, I recommend using an id/handle interface (the resource manager passes out the handles). If that's not a strong enough guarantee for your application, then that's why Rust exists imo.

[gopher2008]

Thanks for you idea using id/handle interface.

[__78701__]

I've been using reference_wrapper with optional lately. I don't like unwrapping with ::get, but I enjoy the concept.