Date: Tue, 29 Oct 2024 18:00:21 +0100
Maybe the proposal is only to push the compiler to automatically apply a
check != nullptr before invoking methods
Il mar 29 ott 2024, 17:43 Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> ha scritto:
> The only member functions theoretically making sense to be called on a
> nullptr are either
>
> a) static functions
>
> b) non-static functions without using *this in their implementation
>
> c) non-static functions using *this, but operating on a default object, if
> the pointer is nullptr
>
>
>
> All three variants won't work or make sense is practice:
>
>
>
> a) the static function can be directly called, if you know the type, e.g.
> with myclass::staticfunction() <- that is probably the only working variant
> and there is a simple working standardized alternative with clear intent
>
> However, if the class is not known/unique at compile-time (e.g. dynamic
> polymporphism), you won't get it from a nullptr either
>
>
>
> b) You do not want to treat non-static functions differently, depending on
> whether they use *this or not (and are more or less like static functions),
> as the calling convention would depend on the implementation of the
> function, which perhaps is not known at the call-site. For non-static
> member functions one should assume that *this is used and has to be valid.
>
> You could enforce that all thus marked functions or all member functions
> in thus marked classes do not use *this. But then you could just use only
> static functions.
>
>
>
> c) If you want to treat nullptr objects as using a default object with
> full class member storage, then each call needs to test for nullptr. This
> can be better (and more generally) be made with some optional wrapper that
> returns a default instance of the object.
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Frederick Virchanza Gotham via Std-Proposals <
> std-proposals_at_[hidden]>
> *Gesendet:* Di 29.10.2024 17:23
> *Betreff:* Re: [std-proposals] Calling methods on a nullptr
> *An:* std-proposals_at_[hidden];
> *CC:* Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>;
> On Tue, Oct 29, 2024 at 2:56 PM Andre Kostur wrote:
> >
> > p->fn(); says that I want to invoke fn() on the object where p is
> pointing.
>
>
> Yeah I agree, I would assume that decltype(*p) is a class that has a
> member function called 'fn'. Or maybe decltype(*p) is a C-style struct
> that contains a member variable which is a function pointer.
>
>
> > But if p is nullptr, then it is not pointing at a valid object, so that
> statement does not make semantical sense.
>
>
> Yeah I agree; currently in C++23, invoking a method on a nullptr
> doesn't make sense.
>
>
> > That one can concoct some mechanism that it will do something is rather
> beside the point.
>
>
> I'm proposing a change to the language.
>
>
> > Additionally, what happens if fn() is a pure virtual function? Yay,
> more UB, just harder to find?
>
>
> In my original post, I suggested a syntax such as:
>
> class MyClass friend nullptr { ... };
>
> to indicate to the compiler that you can invoke methods on a nullptr
> for this class. And so if 'MyClass' contains any methods lacking an
> implementation, the compiler shall terminate compilation and issue a
> diagnostic.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
check != nullptr before invoking methods
Il mar 29 ott 2024, 17:43 Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]> ha scritto:
> The only member functions theoretically making sense to be called on a
> nullptr are either
>
> a) static functions
>
> b) non-static functions without using *this in their implementation
>
> c) non-static functions using *this, but operating on a default object, if
> the pointer is nullptr
>
>
>
> All three variants won't work or make sense is practice:
>
>
>
> a) the static function can be directly called, if you know the type, e.g.
> with myclass::staticfunction() <- that is probably the only working variant
> and there is a simple working standardized alternative with clear intent
>
> However, if the class is not known/unique at compile-time (e.g. dynamic
> polymporphism), you won't get it from a nullptr either
>
>
>
> b) You do not want to treat non-static functions differently, depending on
> whether they use *this or not (and are more or less like static functions),
> as the calling convention would depend on the implementation of the
> function, which perhaps is not known at the call-site. For non-static
> member functions one should assume that *this is used and has to be valid.
>
> You could enforce that all thus marked functions or all member functions
> in thus marked classes do not use *this. But then you could just use only
> static functions.
>
>
>
> c) If you want to treat nullptr objects as using a default object with
> full class member storage, then each call needs to test for nullptr. This
> can be better (and more generally) be made with some optional wrapper that
> returns a default instance of the object.
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Frederick Virchanza Gotham via Std-Proposals <
> std-proposals_at_[hidden]>
> *Gesendet:* Di 29.10.2024 17:23
> *Betreff:* Re: [std-proposals] Calling methods on a nullptr
> *An:* std-proposals_at_[hidden];
> *CC:* Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>;
> On Tue, Oct 29, 2024 at 2:56 PM Andre Kostur wrote:
> >
> > p->fn(); says that I want to invoke fn() on the object where p is
> pointing.
>
>
> Yeah I agree, I would assume that decltype(*p) is a class that has a
> member function called 'fn'. Or maybe decltype(*p) is a C-style struct
> that contains a member variable which is a function pointer.
>
>
> > But if p is nullptr, then it is not pointing at a valid object, so that
> statement does not make semantical sense.
>
>
> Yeah I agree; currently in C++23, invoking a method on a nullptr
> doesn't make sense.
>
>
> > That one can concoct some mechanism that it will do something is rather
> beside the point.
>
>
> I'm proposing a change to the language.
>
>
> > Additionally, what happens if fn() is a pure virtual function? Yay,
> more UB, just harder to find?
>
>
> In my original post, I suggested a syntax such as:
>
> class MyClass friend nullptr { ... };
>
> to indicate to the compiler that you can invoke methods on a nullptr
> for this class. And so if 'MyClass' contains any methods lacking an
> implementation, the compiler shall terminate compilation and issue a
> diagnostic.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2024-10-29 17:00:38