[PATCH] Allow lazy construction of hash_{table,set,map}

[Richard Biener]

On Wed, 20 Mar 2019, Jakub Jelinek wrote:

> On Wed, Mar 20, 2019 at 05:32:16PM -0400, Jason Merrill wrote:
> > > Does this look reasonable, or do you have other proposals?
> > 
> > IMO if you need to guard usage with
> > 
> > +      if (some_type_hash_table.size () == 0)
> > +	some_type_hash_table.create ();
> > 
> > this isn't any better than
> > 
> >   /* Create the constexpr function table if necessary.  */
> >   if (constexpr_fundef_table == NULL)
> >     constexpr_fundef_table
> >       = hash_table<constexpr_fundef_hasher>::create_ggc (101);

I agree - the proposed API is a bit too fragile to be maintainable
IMHO.

> Well, this is surely more costly in that it allocates both the hash_table
> structure and the memory pointed by it from GC.

You could use

  char constexpr_fundef_table[sizeof(hash-table)];
  bool constexpr_fundef_table_initialized_p = false;

  if (!constexpr_fundef_table_initialized_p)
    new (constexpr_fundef_table) hash-table (...);

and hide this pattern behind a new RAII class?

> > Better I think would be to make the member functions handle null m_entries
> > sensibly.
> 
> The goal was not to slow down all current hash_{table,set,map} uses by
> adding runtime checks if m_size is 0 or m_entries is NULL or similar
> (and also grow code size that way).

Yeah, I also think this isn't the very best thing to do.

> I guess another option would be to make the decision whether
> the hash_{table,set,map} is constructed with allocation right away (and no
> runtime checks for it) or if it is lazy another template argument (bool
> Lazy = false before the Allocator template argument), if !Lazy, it would
> work exactly as it is now, if Lazy it would not allocate it in the ctor
> and where needed would add m_entries checks.

That's a possibility, but what about the above RAII trick?  Not sure
if there's a way to avoid the char[] use and instead use "unconstructed"
properly typed storage.

Richard.