Boost logo

Boost :

Subject: Re: [boost] [GIL] Can image::recreate reuse the memory?
From: TONGARI (tongari95_at_[hidden])
Date: 2013-04-25 23:30:16


2013/4/26 Christian Henning <chhenning_at_[hidden]>

> On Wed, Apr 24, 2013 at 10:44 PM, TONGARI <tongari95_at_[hidden]> wrote:
>
> > 2013/4/25 Christian Henning <chhenning_at_[hidden]>
> >
> > > >
> > > > On Sun, Apr 14, 2013 at 7:15 PM, Christian Henning <
> > chhenning_at_[hidden]
> > > >wrote:
> > > >
> > > >>
> > > >> Well, after a deeper look, some ctors need _align_in_bytes from
> > another
> > > >>> image... if you don't care an extra data member, it's still doable.
> > > >>>
> > > >>> Or maybe I should cook me own :(
> > > >>>
> > > >>>
> > > >>
> > > I have added a fix to reuse memory when an image is smaller than the
> > older
> > > one. Would you mind having a look and give me some feedback?
> > >
> >
> > Unfortunately I think this is buggy for deallocate.
> > Since _view's dimensions are changed after recreated, you can't get the
> > original capacity from the changed dimensions.
> >
> > Capacity must be kept to make deallocate right.
> >
> > You are absolutely correct! But I think it's enough to keep the original
> dimensions so the deallocate( ... ) call in the destructors frees the
> correct amount of memory.
>

I can't see why you prefer dimensions (2 ints) to capacity (1 size_t),
seems to me that using capacity has both space & time efficiency (i.e. no
need to recompute total_allocated_size_in_bytes);

> > BTW, I've made my own image type which accepts align as a template param
> > instead.
> >
> > I could see this making sense. Is it just exchanging the member with an
> int template parameter?

And it stores capacity instead, I also improved the align-function a bit.

I'm a bit worries of breaking too much code when
> introducing into boost. What do you think?
>

It'd be better not to break the API (not sure if ABI matters) so I didn't
propose the change, instead, we could have another one as I did for myself.

Regards,


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk