On Mon, Mar 25, 2019 at 03:10:04PM -0400, Jason Merrill wrote:
> > 2) has the false -> true fixed
> > 3) ditto, but furthermore is moved out of add_capture into the lambda
> > introducer parsing routine only, tests for [this, this] and [this, *this]
> > etc. are done using LAMBDA_EXPR_THIS_CAPTURE
On 3/21/19 1:48 PM, Jakub Jelinek wrote:
On Thu, Mar 21, 2019 at 10:25:25AM -0400, Jason Merrill wrote:
Attached (so far without changelog, selftest additions and only tested with
make -j32 -k check-c++-all RUNTESTFLAGS="dg.exp='pr89767.C *lambda* *desig*'"
) is
1) hash_{table,set} implementati
On 3/21/19 1:48 PM, Jakub Jelinek wrote:
On Thu, Mar 21, 2019 at 10:25:25AM -0400, Jason Merrill wrote:
Attached (so far without changelog, selftest additions and only tested with
make -j32 -k check-c++-all RUNTESTFLAGS="dg.exp='pr89767.C *lambda* *desig*'"
) is
1) hash_{table,set} implementati
On Thu, Mar 21, 2019 at 10:25:25AM -0400, Jason Merrill wrote:
> > Attached (so far without changelog, selftest additions and only tested with
> > make -j32 -k check-c++-all RUNTESTFLAGS="dg.exp='pr89767.C *lambda*
> > *desig*'"
> > ) is
> > 1) hash_{table,set} implementation for lazy allocation
On 3/21/19 5:03 AM, Jakub Jelinek wrote:
On Thu, Mar 21, 2019 at 09:28:06AM +0100, Richard Biener wrote:
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)];
On Thu, Mar 21, 2019 at 09:28:06AM +0100, Richard Biener wrote:
> > 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_tabl
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_tab
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
>
> /*
On 3/20/19 1:12 PM, Jakub Jelinek wrote:
Already in the PR71446 patch I used ugly and slow code to avoid allocating
memory in a hash_set all the time, even when it will be used only rarely and
in PR89767 I've reached it again.
While e.g. a vec is POD that even doesn't have a constructor and auto
Hi!
Already in the PR71446 patch I used ugly and slow code to avoid allocating
memory in a hash_set all the time, even when it will be used only rarely and
in PR89767 I've reached it again.
While e.g. a vec is POD that even doesn't have a constructor and auto_vec
has quite a cheap ctor, hash_set/
10 matches
Mail list logo
