1

In the C++ Core Guidelines std::optional is only referred once:

If you need the notion of an optional value, use a pointer, std::optional, or a special value used to denote “no value.”

Other than that, it is not mentioned in the guidelines, so in particular there is no recommendation to use it instead of a pointer, when expressing the intent of an optional value.

Are there any disadvantages of the usage of std::optional in comparison to a pointer that might be null in a non-polymorphic context?

So std::optional is only referred as a side note and as the second option to a pointer. To me it seems like that std::optional is much more expressive. When using a pointer, you can never be really sure if the option of a nullptr is intended.

Henk
  • 826
  • 3
  • 14
  • 1
    this question lacks context. The only part you do quote does mention `std::optional`. – 463035818_is_not_an_ai Nov 16 '22 at 11:31
  • 1
    where do you miss `std::optional` being mentioned? – 463035818_is_not_an_ai Nov 16 '22 at 11:36
  • 6
    "Why is the usage of `std::optional` not recommended" It *is* recommending `std::optional` – Caleth Nov 16 '22 at 11:39
  • [Overhead](https://wandbox.org/permlink/VabQmA79Rh3Jj3zV)? – Paul Sanders Nov 16 '22 at 11:39
  • 2
    `std::optional` does not dynamically allocate the stored object. Whether this is an advantage or disadvantage depends, but it is not equivalent to passing a pointer. Suppose you have a function like this: `void foo(SomeCustomTypeThatIsExpensiveToCopy *);`. You wouldnt refactor this to use `std::optional` (at least not without also doing heavy refactoring on the calling code) – 463035818_is_not_an_ai Nov 16 '22 at 11:39
  • 3
    @PaulSanders https://wandbox.org/permlink/2cfuOMy2ep9EhaWw ;) – 463035818_is_not_an_ai Nov 16 '22 at 11:41
  • The line you quoted very much ***DOES*** recommend `std::optional`. – Galik Nov 16 '22 at 12:54
  • @Galik The point is that this is the only place where it mentions `std::optional`. There is no rule that says that you should prefer to use `std::optional` over a pointer when you want to express this intent. The question is about the absent of this rule. – Henk Nov 16 '22 at 14:19
  • Then maybe the title of the question could be improved a little? – Galik Nov 16 '22 at 14:34
  • @463035818_is_not_a_number Yes, my mind did start to run along those lines but life got in the way – Paul Sanders Nov 17 '22 at 11:55

1 Answers1

3

That guideline is not listing things in order of "pick this first". It is listing options that are appropriate in different situations, and leaves it up to you which is most appropriate for your situation.

In particular, choosing between (const)T* and std::optional<T> is the same as choosing between (const)T& and T. Adapting the examples of the enclosing rule, you'd have

// optional<int> is cheap to copy, pass by value
optional<int> multiply(int, optional<int>); 

// suffix is optional and input-only but not as cheap as an int, pass by const*
string& concatenate(string&, const string* suffix); 

Aside: If you follow the other guidelines, then you can be sure that a pointer indicates a situation where "no value" is an expected case.

Caleth
  • 52,200
  • 2
  • 44
  • 75
  • Sure, if you can assume that everyone uses the guidelines, then a pointer can always be `nullptr` and this represents meaning. However, when you read code of someone else, you do not know what principles it follows. – Henk Nov 16 '22 at 14:21
  • 1
    @Henk independent of what guidline one follows, as a writer of the function you have to assume that a pointer can be `nullptr`, then you are on the safe side. As a user of a function you can assume that it is either documented or `nullptr` is a valid argument to a function taking a raw pointer, or you can consider the function broken. – 463035818_is_not_an_ai Nov 17 '22 at 09:59