/*Me ends lurking*/ As far as allocators go, you may want to take a look at how eastl handles them:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#eastl_allocator /*Resumes Lurking*/ Andrei Alexandrescu Wrote: > bearophile wrote: > > Andrei Alexandrescu: > >> As far as I can tell such changes of containers are a design-time > >> decision, and extremely rarely (never as far as I remember) a runtime > >> decision to hide behind a binary interface. > > > > In your post there's lot of stuff to think about. I can see you are trying > > to innovate, so here's a comment about data structures of the future. In > > Gcc 4.5 they have added a profile mode: > > > > http://gcc.gnu.org/onlinedocs/libstdc++/manual/profile_mode.html > > It gives you simple suggestions, based on simple statistics collected at > > run-time, about data structures choice. > > > > Today data structures are mostly chosen at compile time by the programmer, > > but once the runtime has those statistics collected at run-time, you can > > think of feeding that data into the program itself at runtime, so data > > structures can adapt themselves. This can be useful for programs that run > > on servers, for minutes, hours or days, where they have to face different > > workloads as time passes. > > > > Bye, > > bearophile > > Good point, perfect. I agree with that, and I meant to massage that > point within the message. A structure that's an e.g. set that adapts its > strategy dynamically depending on load is a perfect example. I still > don't think that's the job of a hierarchy - it's the encapsulation of an > algebraic type together with a strategy for choosing the type currently > used. > > Apologies for the dense message. I wanted to concentrate as much info in > as little time/space as possible. > > > Andrei
