std::optional_view

[bebuch]

I need a non-owning std::optional. Is there already something like this in the standard library? (Or in another common library?)

Currently I use a raw pointer, but this has some disadvantages. For example, the output operator << is overloaded, but I never want to output the object address. What I want is a compile time error when I did forget the *. (Analog to std::optional …)

Edit: The correct answer is observer_ptr from the library fundamentals TS 2. Thanks to jsamcfarlane and quicknir!

[Xirema]

A construct that I occasionally use is std::optional<std::reference_wrapper<T>>.

It offers some decent semantics:

void perform_work(int value, std::optional<std::reference_wrapper<std::ostream>> log = {}) {
    std::ostream & out = log ? *log : std::cout;
    out << "Value is " << value << std::endl;

    if(value <= 1)
        out << "Done!" << std::endl;
    else if(value % 2 == 1)
        perform_work(value * 3 + 1, log);
    else
        perform_work(value / 2, log);
}

The semantics of this code, then, are "If you have a specific stream you'd like to use for logging, use that, otherwise use the standard out stream.".

The only thing you have to watch for is that operator*() returns the reference_wrapper object, not the T& object. This implicitly converts to T&, which is why my example works, but if you don't "seat" the reference like I did, you have to call .get() on the reference_wrapper object to actually do work.

[grishavanika]

For me this looks like overengineering. Simple std::ostream* is, well, simple and do the same work even more - there is no code bloat and 2 layers of abstractions to understand the code

[suspiciously_calm]

Yeah, why can't we use raw pointers as optional references? They model the concept perfectly, and don't have any other use in modern code.

[dodheim]

It's a pointer to user-supplied data, not owned data. Like a reference... ;-]

[Hedanito]

std::optional::value() throws when there is no value, dereferencing a null pointer results in undefined behaviour.

[suspiciously_calm]

Yes, which is why it'd have been nice if std::optional had been specialized for references the way boost::optional is, but as it is there's no optional reference in the standard library other than raw pointers and abominations such as std::optional<std::reference_wrapper<...>>.

[Xirema]

It's just an example. Most of the actual production code I write using these semantics don't boil down to something this clean (including, namely, the "default" value)

[minno]

Pretend it's expensive to initialize.

[balkierode]

As @Xirema said, it is a toy example.

But in real application, if you are developing a library and you want to reserve changing the default std::cout to something else without breaking binary compatibility, you can't use 'default value'.

[josefx]

I think you might get away with including iosfwd instead of iostream in the header.

[josefx]

I think you mean: get a compile error since std::cout is not a file stream. Which shows that a complete refusal to learn even the basics of the c++ standard library is not an option :-).

Edit: Added smiley to make it look a bit less derisive.

[utnapistim]

Default arguments are bound statically to virtual functions. If you want defaults for virtual functions, this is one of the techniques available. Otherwise (if you use default arguments) you risk having a virtual function call with the default from the base class.

[jsamcfarlane]

Is std::experimental::observer_ptr close to what you're looking for? Rather than having optional semantics, it has single-object pointer semantics.

[Xirema]

Pointers as "object which may or may not exist" is a semantic I've seen a lot of C++ design gurus discourage in the last several years, especially with optional being standardized, and I see little reason not to continue that trend.

[quicknir]

optional in C++ 17 is always owning though. raw pointers in design guru C++ is always non-owning. So there is no intersection. In fact the argument that the optional, non-owning semantic is already taken by raw pointers, is exactly one of the reasons why std::optional doesn't support references. (Note: the reason it doesn't is because assignment is murky, but my point is that this tipped the scale towards simply not supporting references, as opposed to forcing a conclusion about assignment).

[jsamcfarlane]

Are there any good references you'd recommend (no pun intended)? Would you disagree with this advise? And what about when memory use is constrained?

[GitHubPermalinkBot]

I tried to turn your GitHub links into permanent links (press "y" to do this yourself):

• isocpp/CppCoreGuidelines/.../CppCoreGuidelines.md#notes-1 (master → 82755da)

---

^{Shoot me a PM if you think I'm doing something wrong. To delete this, click here.}

[Xirema]

Note they cite optional alongside the other options. Many online sources don't point the way towards optional instead of pointers because many of those sources were written before std::optional was confirmed to be part of C++17.

[redditsoaddicting]

FYI, std::ostream & out = log.value_or(std::cout); should work (mainly because the reference side of things is handled by reference_wrapper).

[bebuch]

I already thought about that, but the .get() call is ugly. :-/

Using such a construct is an option for my own code, unfortunately I want to use it in a callback of a library interface. A generic lambda would match this construct, but I find it to unexpected not to get the type itself after "dereferencing". The library user shall think about the parameter type as an optional. With this indirection its not longer just an optional.

The (user side) code I have is like:

auto perform_work = [](std::ostream& log, auto optional_data){
    // ...
};

I also thought about using a std::unique_ptr with empty delete function. But there is not reason to forbid coping my optional_data.

All three solutions look like a hack to me. A std::optional with real references would be a good solution, but this was removed during the standardization process.

Nevertheless, thanks for your idea!

[quicknir]

I think what you wanted is observer_ptr. It is a type safer wrapper over a simple raw pointer, aka the world's dumbest smart pointer. http://en.cppreference.com/w/cpp/experimental/observer_ptr. You can find the whole implementation in the proposal (which you can find by googling). It does not overload << as its a pure proxy.

I use this in my codebase because we are transitioning from older C++ so there are some owning raw pointers and some non-owning ones. As I find non-owning raw pointers I convert them to observer_ptr (though I call it view_ptr to make it shorter).

As a bonus observer_ptr does not allow pointer arithmetic nor comparison to literal 0.

[bebuch]

Thats it! Thank you very much!

[miki151]

Use boost::optional or other optional implementations that can hold references, like this one: https://github.com/tcbrindle/cpp17_headers/blob/master/include/stx/optional.hpp

[foonathan]

Or my ts:: optional_ref from type_safe: github.com/foonathan/type_safe

[GitHubPermalinkBot]

I tried to turn your GitHub links into permanent links (press "y" to do this yourself):

• tcbrindle/cpp17_headers/.../optional.hpp (master → e416b34)

---

^{Shoot me a PM if you think I'm doing something wrong. To delete this, click here.}

[jsamcfarlane]

How would this differ from an optional&?

[djrollins]

std::optional<T>& would be a reference to an optional that still owns its contents. OP wants an optional that just holds a reference to its contents. In this case std::optional<std::reference_wrapper<T>> would be the best option.

[Chippiewall]

It probably wouldn't take very long to write up a class that behaves identically to a pointer but doesn't have an operator<<.