[boost] Re: Re: Re: Re: what happened to allocators in boost?
Peter Dimov wrote: > Andreas Huber wrote: >> Peter Dimov wrote: >>> The usual approach is to borrow an entry from the 2*N heap and split >>> it in two when the N heap is empty. [snip] >> >> Which brings back non-determinism, as the 2*N heap could be full also >> and thus be borrowing from 4*N already. You can of course guarantee >> an upper limit for an allocation, as some heap must have a slot >> available. > > Actually it's possible that all free memory already went to the N/2 > heap but this case is (even more) unsolvable with predetermined heap > sizes, too. :-) > >> However, for some systems this upper limit is already too slow, so >> someone inevitably has to configure heap sizes *before* startup. > > I agree, but I still don't see why a quality system allocator on such > a system should not give you the ability to do so. True, but this is just not yet standard. Not that I have an awful lot of experience with such systems but the (very popular) platform of the one project I was involved with was far away from providing such a quality allocator. Regards, Andreas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: what happened to allocators in boost?
Andreas Huber wrote: > [snip] >>> However, for a certain class of systems one almost never can avoid >>> customization, no matter how ingenious the platform is. >> >> This may well be true, but I'm not convinced that platform-specific >> customizations (an implementation detail) absolutely need to be >> supported by a portable mechanism affecting the interface. > > I see your point but what is the alternative? Forcing people to > replace global new/delete? In a word, yes. Although replacing global new/delete is forced by the system allocator being not up to the task and not by us. I understand that for some applications region-based memory management can be a big performance win. I also understand that some (uncommon in my experience) cases can't be supported by a global allocator (when two independent regions are active at once, in a single thread.) But I'm not sure that Allocators (as spelled in the standard) are the answer, and I'm entertaining the thought that in the long term this kind of customization harms the C++ community. Maybe not one's particular corner of the community, but the community as a whole. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: what happened to allocators in boost?
[snip] >> However, for a certain class of systems one almost never can avoid >> customization, no matter how ingenious the platform is. > > This may well be true, but I'm not convinced that platform-specific > customizations (an implementation detail) absolutely need to be > supported by a portable mechanism affecting the interface. I see your point but what is the alternative? Forcing people to replace global new/delete? Regards, Andreas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
