C++ Logo

std-discussion

Advanced search

Re: Indirection of nullptr that is not really done

From: Yongwei Wu <wuyongwei_at_[hidden]>
Date: Sat, 22 Jun 2024 21:32:40 +0800
On Sat, 22 Jun 2024 at 15:41, Jens Maurer <jens.maurer_at_[hidden]> wrote:
> > https://cplusplus.github.io/CWG/issues/2823.html
> >
> > According to this issue, ptr->h() is undefined.
>
> That's the result, yes.

Consider this variant:

class Obj {
public:
    constexpr int f() { return d_; }
    constexpr int g() { return 0; }
    constexpr static int h() { return 1; }

private:
    int d_{};
};

constexpr auto ptr = static_cast<Obj*>(nullptr);
constexpr int n1 = ptr->f();
constexpr int n2 = ptr->g();
constexpr int n3 = ptr->h();

Will the standard require all the last three lines to generate errors,
as required by [expr.const]/5.8?
https://eel.is/c++draft/expr.const#5.8

It seems to me a burden to the compilers, though I have no idea how
difficult it is to implement it.

Currently, only the n1 line generates errors in the three main
compilers I tested. The n3 line does not even trigger a warning.

Due to the requirement that undefined behavior should mostly not occur
in constant expressions, they have a cost to compilers.

-- 
Yongwei Wu
URL: http://wyw.dcweb.cn/

Received on 2024-06-22 13:32:53