On 2020-02-16 at 05:45, J Decker via Std-Proposals wrote:
>
>
> On Sat, Feb 15, 2020 at 8:40 PM Arthur O'Dwyer
> <arthur.j.odwyer_at_[hidden] <mailto:arthur.j.odwyer_at_[hidden]>> wrote:
>
>
> On Sat, Feb 15, 2020 at 11:10 PM J Decker <d3ck0r_at_[hidden]
> <mailto:d3ck0r_at_[hidden]>> wrote:
>
> On Sat, Feb 15, 2020 at 7:07 PM Arthur O'Dwyer
> <arthur.j.odwyer_at_[hidden] <mailto:arthur.j.odwyer_at_[hidden]>>
> wrote:
>
> Hi Jim,
>
> Sadly your idea doesn't work in C++, because C++ has
> /*member functions*/. That is, we can write things like this:
>
> struct Widget {
> void reset(); // reset the widget
> };
> [...]
> std::unique_ptr<Widget> p = std::make_unique<Widget>();
> p->reset(); // reset the pointed-to widget by calling
> Widget::reset() member function
> p.reset(); // reset the pointer's own value to nullptr
>
>
> But, isn't the .reset() implemented on the unique_ptr<> template
> as a operator. override? which takes precedence over the
> default behavior...
>
>
> No, C++ doesn't permit overloading the "." operator at all.
> It's just that `p.reset()` calls `unique_ptr<Widget>::reset`,
> and `p->reset()` calls `unique_ptr<Widget>::operator->` followed by
> `Widget::reset`.
>
> I think you'll have to learn more about how C++ currently works,
> before working on proposals to change it.
>
> A appricate you leveraing my acknowledgment of limitation as a
> dismissal; it's more a factor that I need to learn the right way to say it.
>
> It doesn't look like that's either a instance of a class/struct/union or
> a pointer to a class/struct/union, but rather is a unique pointer to a
> class/struct/union.

It's just that unique_ptr *is* a class from the C++ standard library.

And that it, like Arthur says, already has both . and -> defined, but
with different meanings. So making the operators mean the same thing
doesn't look as a good idea, as it breaks existing code.


     Bo Persson