This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH to implement C++20 P0892R2 - explicit(bool)
- From: Marek Polacek <polacek at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 2 Oct 2018 17:25:50 -0400
- Subject: Re: C++ PATCH to implement C++20 P0892R2 - explicit(bool)
- References: <20181001224137.GN5587@redhat.com> <CADzB+2mVkQ0FqXHjR-3odjA=6HGUQ0Dc1Gya-Zs1oUXMpi66bQ@mail.gmail.com>
On Mon, Oct 01, 2018 at 07:47:10PM -0400, Jason Merrill wrote:
> On Mon, Oct 1, 2018 at 6:41 PM Marek Polacek <polacek@redhat.com> wrote:
> >
> > This patch implements C++20 explicit(bool), as described in:
> > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0892r2.html>.
> >
> > I tried to follow the noexcept specifier implementation where I could, which
> > made the non-template parts of this fairly easy. To make explicit(expr) work
> > with dependent expressions, I had to add DECL_EXPLICIT_SPEC to lang_decl_fn,
> > which serves as a vessel to get the explicit-specifier to tsubst_function_decl
> > where I substitute the dependent arguments.
>
> What's the impact of that on memory consumption? I'm nervous about
> adding another word to most functions when it's not useful to most of
> them. For several similar things we've been using hash tables on the
> side.
Yeah, that is a fair concern. I'm not sure if I know of a good way to measure
it. I took wide-int.ii and ran /usr/bin/time -v ./cc1plus; then it's roughly
Maximum resident set size (kbytes): 95020
vs.
Maximum resident set size (kbytes): 95272
which doesn't seem too bad but I don't know if it proves anything.
If we went with the hash table, would it work like this?
1) have a hash table mapping decls (key) to explicit-specifiers
2) instead of setting DECL_EXPLICIT_SPEC put the parsed explicit-specifier
into the table
3) in tsubst_function_decl look if the fn decl is associated with any
explicit-specifier, if it is, substitute it, and set DECL_NONCONVERTING_P
accordingly.
> > +/* Create a representation of the explicit-specifier with
> > + constant-expression of EXPR. COMPLAIN is as for tsubst. */
> > +
> > +tree
> > +build_explicit_specifier (tree expr, tsubst_flags_t complain)
> > +{
> > + if (processing_template_decl && value_dependent_expression_p (expr))
> > + /* Wait for instantiation. tsubst_function_decl will take care of it. */
> > + return expr;
> > +
> > + expr = perform_implicit_conversion_flags (boolean_type_node, expr,
> > + complain, LOOKUP_NORMAL);
> > + expr = instantiate_non_dependent_expr (expr);
> > + expr = cxx_constant_value (expr);
> > + return expr;
> > +}
>
> Is there a reason not to use build_converted_constant_expr?
build_converted_constant_expr doesn't allow narrowing conversions but we should
allow them in explicit-specifier which takes "contextually converted constant
expression of type bool", much like in
constexpr int foo () { return 42; }
static_assert (foo());
Right?
Marek