Hi Tobias,
> first, thanks Trevor for the first round of review!
Also thanks from my side!
> I still see:
>> - expr_count = 0;
>> + expr_array.truncate (0);
>
> Is there is a reason for not using release() here?
No, changed in the committed version.
Regards
Thomas
Hi Thomas, hi all,
first, thanks Trevor for the first round of review!
Thomas Koenig wrote:
> Trevor Saunders wrote:
> > >doloop_warn (ns);
> > > - XDELETEVEC (doloop_list);
> > > + doloop_list.truncate (0);
> >
> > .release () would be more typical.
>
> Changed (also below).
I still see:
Hi,
Trevor Saunders wrote:
>> -static gfc_expr ***expr_array;
>> -static int expr_size, expr_count;
>> +static vec expr_array = vec();
>
> that's usually written as just static vec foo; vec doesn't actually
> have ctors, and 0 initialization works fine.
Fixed (also below).
>> + // doloop_li
On Sun, Aug 24, 2014 at 12:47:17AM +0200, Thomas Koenig wrote:
> Hello world,
>
> the attached patch uses the vec<> templates instead of the
> home-grown memory management.
>
> Did I get the style right? I was a bit confused because, with
> the declarations used in the patch, using the vec_safe_
On Sun, Aug 24, 2014 at 12:47:17AM +0200, Thomas Koenig wrote:
> Hello world,
>
> the attached patch uses the vec<> templates instead of the
> home-grown memory management.
>
> Did I get the style right? I was a bit confused because, with
> the declarations used in the patch, using the vec_safe_
Hello world,
the attached patch uses the vec<> templates instead of the
home-grown memory management.
Did I get the style right? I was a bit confused because, with
the declarations used in the patch, using the vec_safe_truncate
function failed with a failure to find the right template.
I'm not a
