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.
