Re: [Objectivelib-discussion] Memory allocator removal?

[Will M. <wil...@us...>]

Thanks very much for getting back to me on this issue, Daniel. I really
appreciate your input.

I've been giving this a lot of thought. The upside is that I let
everyone else worry about memory management. The downside is that users
will no longer have any control over how collections manage their
memory. Theoretically, I could make sure that under Cocoa/GNUstep every
object would be copied with the zone indicated by copyWithZone:, but
that sounds like a lot of not-very-productive work, especially since
all of that would go out the window in a non-Cocoa/GNUstep environment.

It's hard to imagine a solution that uses ObjectiveLib memory
allocators that isn't half-baked, but part of me wonders whether that's
just because I'm not creative enough. The only reason I considered
specialized memory allocators to begin with was because they were an
integral part of STL, but how many people actually use custom
allocators in STL? I've used STL professionally for years and never
even considered them once. I'll bet more than 99% of users would report
a similar usage pattern.

Anyway, having someone tell me what they think is really helpful. And
in this case, Daniel, you were the primary motivator behind what I'm
dealing with now, so you owe it to me to participate in the discussion.

Thanks very much,
Will

--- Daniel Rasmussen <ra...@cs...> wrote:

> That sounds like a good solution. Although potentially useful,  
> allocators aren't needed, and alloc/dealloc would be consistent with 
> 
> everything else. Better to leave allocators out than try to fudge  
> around with half-baked solutions.
> 
> -Daniel
> 
> 
> On Aug 1, 2005, at 4:27 PM, Will Mason wrote:
> 
> > I'm in the process of eliminating dependencies on Cocoa/GNUstep for
> > ObjectiveLib. The memory allocator code barely works under
> > Cocoa/GNUstep, but it completely fails in an Object-based system.
> The
> > reason is that instead of using retain/release to hang onto and un-
> 
> > hang
> > onto objects, you have to copy the object and later free it.  
> > There's no
> > way to rely on a generic copy method for any given class that will 
> 
> > make
> > use of a desired allocator, as the copy-related methods in Object
> have
> > no knowledge of ObjectiveLib memory allocators. This means that
> > although an OLVector, for example, can allocate its memory cache
> using
> > a given allocator, it can't copy the objects that it manages using
> a
> > given allocator. This results in half-baked memory management.
> >
> > I'm considering eliminating memory allocators as they currently
> exist
> > in ObjectiveLib in favor of letting people fall back to overriding
> > alloc and free/dealloc in order to get specialized memory
> management
> > for a given class. This will work equally well with all
> ObjectiveLib
> > classes and all other classes, too.
> >
> > I was hoping to get some feedback on this idea before I gut the  
> > system.
> >
> > Thanks for any advice,
> > Will
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Objectivelib-discussion mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectivelib-discussion
>