This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stl_vector.h?!? (Re: [libstdc++] PATCH: STL allocator cleanup,part 1)


I think the ext allocators can move to standard-conforming allocator
style immediately, right? That work can proceed independently of the
_Alloc_traits removal.

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

Agreed, again.

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

Yes.... have you given any thought to a way to configure the default
allocator? There was some hand-waving about this awhile back. I still
don't see a good way to do this. 

I bring this up, because I'm not convinced that __pool_alloc is really
the best solution for a default allocator for thread-enabled, SMP
systems. 

I guess if there was a __single_pool_allocator and a
__multi_pool_allocator in /ext, then we could use the namespace
association trick to inject them correctly into std, then typedef to
std::allocator depending on configure flags/macros? Vague, I know, but
feasible?

Does anybody else do configurable allocators in an STL implementation?
Or ship with alternate allocators? What do they do?

>If you're reimplementing the allocators in the ext directory, I suggest
>that you get rid of the 'inst' template parameter.  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.

Absolutely.

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

Yeah. Any ideas? I'll do the work for malloc_alloc, new_alloc, and
mt_alloc but hold off on checking it in until the names solidify. That
should keep me out of your hair.

;)

-benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]