C++ Logo

STD-PROPOSALS

Advanced search

Subject: Re: [std-proposals] Ptr proposal: looking for feedback
From: Arthur O'Dwyer (arthur.j.odwyer_at_[hidden])
Date: 2020-07-17 09:55:12


On Fri, Jul 17, 2020 at 10:50 AM Ville Voutilainen <
ville.voutilainen_at_[hidden]> wrote:

> On Fri, 17 Jul 2020 at 17:40, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> wrote:
> > But if that were actually the only use-case, then we wouldn't need
> ptr<T> at all! There's already an idiomatic C++ way of doing that:
> > void betterfunc(Foo& f);
> > ... betterfunc(local); ... // no ownership
> > ... betterfunc(*std::make_unique<Foo>(42)); // construct an owning
> unique_ptr, and then deallocate it afterward
> > If the parameter `Foo& f` were const-qualified, we could even do this:
> > ... betterfunc(Foo(42)); ... // construct a Foo and deallocate it
> afterward, without even using the heap!
>
> ..but if the parameter of betterfunc is supposed to be nullable, none
> of that nonsense works.
>

If it's supposed to be nullable, pass a pointer. Since you don't want to
mess with ownership, pass a raw pointer.

    void betterfunc(Foo *pf);
    ... betterfunc(&local); ... // no ownership
    ... betterfunc(std::make_unique<Foo>(42).get()); ... // construct an
owning unique_ptr, and then deallocate it afterward
    ... betterfunc(nullptr); ... // pass null

Calling it "nonsense" is a bit much. Trust me; I do this stuff for a
living, and also teach it. :)
Most recently, see my CppCon 2019 presentation "Back to Basics: Smart
Pointers <https://www.youtube.com/watch?v=xGDLkt-jBJ4>."

–Arthur



STD-PROPOSALS list run by herb.sutter at gmail.com

Standard Proposals Archives on Google Groups