--- Peter Dimov <[EMAIL PROTECTED]> wrote: > E. Gladyshev wrote: > > --- Peter Dimov <[EMAIL PROTECTED]> wrote: > > > >> unless there are very solid reasons for the allocator parameter. ;-) > > > > I agree, but the problme is that I don't know whether I have a solid > reason or not. > > I have to ship my class to someone else. She might have a solid reason, I > don't know. > > If I supply an allocator parameter, then I am covered and I can sleep > well. :) > > Well... if you ask me, it is better to not offer the functionality until > someone explicitly asks for it and gives a reasonable scenario as an > example. Features are easy to add, hard to remove, and there is always the > possibility that you "pre-included" the wrong feature.
Ok, I'll let my users know who is to blame. :) I agree, if I am to use boost, providing an allocator parameter doesn't make much sense. shared_ptr news the ref counter and in general, boost doesn't allow a full memory management customization anyway. I agree that the STL allocators may not be the answer but then, what is. Counting on the standard allocator is certainly not an answer either. I am afraid that some of the boost libraries (as they are now) won't work for a big group of real time and embedded developers, where customization is the key. Eugene __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
