Boost logo

Boost :

Subject: Re: [boost] [GIL] Can image::recreate reuse the memory?
From: Christian Henning (chhenning_at_[hidden])
Date: 2013-06-01 11:03:29


Sorry for the very late reply.

> The function create_view is only called when reusing the image's memory. I
> > guess I don't understand what you mean.
> >
>
> For example, look line 313: the memory address 'tmp' is aligned which may
> differ from '_memory'.
>
> So you can't recreate the view with _memory, instead, you should use the
> aligned address.
>
>
I understand now. I fixed it.

>
> > > 2) In 'recreate': You have to update _align_in_bytes before calling
> > > create_view
> > >
> >
> > When the user recreates an image with a different _align_in_bytes we need
> > to reallocate the memory. I added this condition to the code. If the
> > alignment doesn't change then I don't need to update the member.
> >
>
> You don't have to test the equality of _align_in_bytes & _alloc...
> Even if _align_in_bytes differs, you could still reuse the space.
> As for _alloc, I'm not sure if you want to guarantee that even if no
> reallocation is needed, as long as the user provide another allocator, the
> whole memory should be allocate by it.
>
>
If the new align_in_bytes is larger than the old one it could mean we have
to reallocate. Do you agree?

I'm not sure how a allocator would be implemented, but since it's a default
> param currently, while the user might just want to use the original one
> (not the implicitly newly constructed one which may != the orignal), it
> might surprise the user if he does care about the allocator used, so my
> suggestion here is to separate it to 2 versions with & without allocator,
> at least, it won't break the API (I personally would like to drop the
> Alloc param here...)
>
>
I have implemented two versions now.

> Last but not least, 'total_allocated_size_in_bytes' also depends on
> '_align_in_bytes', so nevertheless, you have to update it first.
>
>
Done.

Regards,
Christian


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