This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: stl_vector.h?!? (Re: [libstdc++] PATCH: STL allocator cleanup, part 1)
On Dec 19, 2003, at 12:00 PM, Benjamin Kosnik wrote:
And I didn't answer your question, Benjamin, but: the answer is yes.
The nonstandard allocators should be written in terms of the standard
interface. My prejudice nowadays is that that should be a general
rule, that extensions shouldn't be written in terms of private
interfaces unless it's absolutely necessary. In this case it isn't
necessary.
Great. I think this makes the most sense too. I think these changes,
when finished, will substantially reduce confusion in user-land. Yay!
When I give these allocators standard interfaces, I'd like to change
their names too. Would anyone object to names like debug_allocator,
pool_allocator, mt_allocator, new_allocator, and malloc_allocator?
Nope! In my proposed patch I already did this for new_allocator. I'm up
for this (although, as a nit, I wish we had better names for
pool_allocator and mt_allocator. Maybe single_pool_allocator and
multi_pool_allocator. That's getting to be kind of a mouthful though.)
I'll work on converting these much the way new_allocator was done.
OK! The only nit: right now, std::allocator depends on __pool_alloc.
That's ugly to begin with (having the default allocator depend on
an extension), and it should be changed.
I think what I'll do is get rid of that dependency, and cannibalize bits
of __pool_alloc for the std:;allocator reimplementation. (The word
"reimplementation" sounds scarier than it really is. Lots of code will
move from one place to another, but there won't be much really new
code. Maybe 'refactoring' would be a more accurate term.)
If you're reimplementing the allocators in the ext directory, I suggest
that you get rid of the 'inst' template paramter. It serves no purpose.
The only reason we put it there was so that we could put the
implementations of nontrivial member functions in header files.
And as long as we're talking about names... The one I really dislike
is "new_allocator". The name is accurate, but it's also really open to
misinterpretation.
--Matt