On Mon, Jul 07, 2003 at 08:03:43AM -0700, Jonathan H.H. Bloedow wrote:
> At 06:46 PM 7/3/2003 -0700, Scott Blachowicz wrote:
> >"Jonathan H.H. Bloedow" <jbloedow at real.com> wrote:
> >
> >> This change is designed to allow the CHXBuffer to keep track of the 
> >size of
> >> the allocation(s) that it has made so that if a buffer is resized down
> >> below its actual allocation size, it can be resized back up to the 
> >original
> >> allocation size without doing a completely unnecessary reallocation.
> >>
> >> Please let me know if you see any problems with this implementation.
> >
> >Would it make more sense to manage m_ulAllocLength in the Allocate(),
> >Reallocate() and Deallocate() methods?
> 
> Yes it would, and that's what I would have done, except those member 
> functions are all "const", which makes it tricky to modify a member 
> variable within them.

Unless you view the m_ulAllocLength member variable as not necessarily
being a "logical" part of the CHXBuffer (rather an implementation
detail)...then you could declare m_ulAllocLength as "mutable" so you could
modify it from "const" methods. I'm not saying that you should do it that
way - just that it's another way to look at it. I frequently use "mutable"
to declare mutex member variables so they can be locked from const methods
(if the the Lock()/Unlock() methods on the mutex object are non-const, then
you can't call them on a non-mutable member var from a const method of the
containing object).

Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe at common.helixcommunity.org
For additional commands, e-mail: dev-help at common.helixcommunity.org