Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar
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