This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ PATCH to implement C++20 P0892R2 - explicit(bool)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]