Re: [Objectivelib-discussion] Memory allocator removal?

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

I still haven't made any decisions on this issue. If I remove OL memory
allocators, then I also remove any possibility of users being able to
control the internal memory management of OL containers. If I don't,
then I guarantee that the in-place memory management system will not do
what users expect on non-Cocoa/GNUstep systems.

Which is the lesser of the two bad things?

Thanks for any help,
Will

--- Will Mason <wil...@us...> wrote:

> 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
> > 
> 
> 
> 
> -------------------------------------------------------
> 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
>