Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c++ > #363

Re: Proposal: constexpr, non-const member functions

Show all headers | View raw

Am 08.11.2011 20:32, schrieb Richard Smith:
>
> Hi,
>
> Pointers and references to non-const objects can generally be used within
> constant expressions in C++11. However, there is a roadblock in the way of
> anyone who wants to use them as the 'this' pointer, because constexpr member
> functions are implicitly const. Consider a trivial class like this:
>
>    template<typename T>
>    class Wrapper {
>      T v;
>    public:
>      constexpr Wrapper(const T&v) : v(v) {}
>      T&get() { return v; } // note, can't be constexpr
>      constexpr const T&get() { return v; }
>      // ...
>    };
>
> This seems fine until you try to use a temporary of this type in a constant
> expression:
>
>    constexpr int n = Wrapper<int>(0).get(); // ill-formed!
>
> This doesn't work, because the non-const (and thus non-constexpr) get()
> overload  is selected.
>
> Since C++11 is already out of the gate, it's too late to remove the 'constexpr
> implies const' rule, so instead we could consider a syntax like this:
>
>    constexpr T&get() mutable { return v; }
>
> Does this seem like a useful extension?

I completely agree with your analysis, I have the exactly same
impression of the status quo and of their inconsistencies. I
originally became aware of it by looking at the two basic kinds of
constant expressions, namely "value"-based ones (especially
rvalue-based), where a constant member function is the natural
solution for it, and "identity"-constant expressions (like
address-constant or reference-constant expressions), where both
constant and non-constant member functions are useful. It makes sense
to allow for a reference-constant expression even for non-const member
functions (or objects), because we can still have references (or
pointers) to non-const objects.

I tend to say that a good long-term suggestion would be to extend
mutable for member functions as you describe - the good news are that
lambda expressions already use this approach, so its not completely
new. My current short-term approach is to use free constexpr functions
as a workaround wherever possible. This is probably not the worst idea
as a general principle anyway, but enforcing it is actual against the
spirit of C++ and does not work for all functions (because some are
required to be member functions).

Greetings from Bremen,

Daniel Krügler




--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Back to comp.std.c++ | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Proposal: constexpr, non-const member functions "Richard Smith"<richard@metafoo.co.uk> - 2011-11-08 11:32 -0800
  Re: Proposal: constexpr, non-const member functions Dave Abrahams <dave@boostpro.com> - 2011-11-08 14:45 -0800
  Re: Proposal: constexpr, non-const member functions Daniel Krügler <daniel.kruegler@googlemail.com> - 2011-11-08 14:47 -0800
  Re: Proposal: constexpr, non-const member functions Marc <marc.glisse@gmail.com> - 2011-11-08 14:47 -0800
    Re: Proposal: constexpr, non-const member functions Daniel Krügler <daniel.kruegler@googlemail.com> - 2011-11-09 21:54 -0800
      Re: Proposal: constexpr, non-const member functions Daniel Krügler<daniel.kruegler@googlemail.com> - 2011-11-09 23:14 -0800

csiph-web