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


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

Re: Proposal: constexpr, non-const member functions

From Daniel Krügler <daniel.kruegler@googlemail.com>
Newsgroups comp.std.c++
Subject Re: Proposal: constexpr, non-const member functions
Date 2011-11-09 21:54 -0800
Organization A noiseless patient Spider
Message-ID <j9d7u2$3ql$2@dont-email.me> (permalink)
References <46713.10.0.7.178.1320718071.squirrel@webmail.secure.aluminati.net> <j9c4b3$dbo$1@news-rocq.inria.fr>

Show all headers | View raw


On 2011-11-08 23:47, Marc wrote:
>
> Funny, there is currently a discussion about this on the gcc bugzilla.
> std::bitset::operator[] has the same problem.
>
> Can't you use *this references to solve this?
>
> T&get()&  { return v; }
> constexpr const T&get()const&  { return v; }

I think you can and this looks like an even better solution for this
particular example from Richard, which still is - based on my
imprecise nomenclature used in my reply to Richard - a constant
"value" expression.

I still think that we might want to allow for using mutable to mark a
non-static constexpr member function as a non-const function in all
cases where you want to conserve address-constness or
reference-constness. Consider this revised example based on Richard's
Wrapper type:

Wrapper<int> wi = ...; // In namespace-scope

constexpr int& ri = wi.get(); // Error
constexpr int* pi = &wi.get(); // Error

IMO there are no good reasons, why this example should be well-formed.
It currently is, because you cannot declare a non-const, but still
constexpr member function. It works fine, if you fall back to free
functions or static member functions, like so:

template<typename T>
class Wrapper {
 T v;
public:
 constexpr Wrapper(const T&v) : v(v) {}
 // ...

 friend constexpr T&get(Wrapper& w) // note, can be constexpr
 { return w.v; }
 friend constexpr const T&get(const Wrapper& w)
 { return w.v; }
};

Wrapper<int> wi = ...; // In namespace-scope

constexpr int& ri = get(wi); // OK
constexpr int* pi = &get(wi); // OK

This shows that constexpr functions do not necessarily need to be
const functions. They usually are, so the current default looks fine
and not like a defect to me. In the much rarer situations where
"identity"-based constant expressions are of interest, you should be
able to declare member functions the same way as free functions.

Summarizing, you may want to allow for the following:

template<typename T>
class Wrapper {
 T v;
public:
 constexpr Wrapper(const T&v) : v(v) {}
 constexpr T& get() mutable & { return v; }
 constexpr const T& get() & { return v; }
 // ...
};

HTH & 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 | NextPrevious 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