Re: [boost] Proposal: Monotonic Containers

Subject: Re: [boost] Proposal: Monotonic Containers
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-06-18 12:44:50

Christian Schladetsch wrote:
> In retrospect, I should have sat on my hat for a few weeks longer,
> decided 
> on the necessity of default-construction myself, created an
> academic-quality paper with references, tables, comparisons, and so
> on. I will do so now, retro-actively and will stop bickering.

I'd be very surprised to learn that there isn't a memory pool out there that allows the user to specify an address and size as the initial buffer.  This address could obviously come from the stack.  You've repeatedly said you are the first or only to do such-and-such, but haven't backed it up.  Have you looked?  If you want to write an allocator you should be well versed in what allocators are available and their relative strengths and weaknesses.  You know there is a difference between gcc and MSVC allocators, but you don't know what that difference is.  I'd like you to be able to answer that question if you are comparing yourself to them.  You can step through their code in the debugger, after all.  Making an allocator thread safe is not generally trivial, so saying you added mutexes and made it thread safe doesn't inspire confidence.  Do you know and understand the pitfalls in this?  Do you know what the double locking pattern is, or why people use it?  Along with a proposal (to boost) for a new allocator you need to be able to present a review of exising allocators and demonstrate mastery of the subject matter (including a historical perspective) so that if your library is accepted and people begin to defer to you as an expert in allocators it is because, in fact, you are an expert in allocators and not just because you are very confident in yourself.  Confidence is not a bad thing.  I'm confident in myself too.  Three years ago I wasn't an expert in much of anything but had some good ideas and some bad ideas.  Be patient.

Regards,
Luke