<Bjorn.Karlsson@readsoft.com> wrote in message news:E6EE2E266803D5118EF400A024A66C310126D4EB@CHEWIE...

[snip]

It's analogy time:

User needs are varied for containers. Thus, we have list, vector, deque, set, map etceteras to choose from, all with different performance guarantees for different operations. This seems like a very reasonable tradeoff, and although I personally wouldn't mind typing std::container<std::red_black_tree>, many users would. Of course, this would tie the interface to the implementation too hard, so I might end up writing std::container<std::logarithmic_time_insertion, std::logarithmic_time_find...> and so on.

And I do not think it it good. In addition to std containers we have array in boost, several other were/is discussed: auto_sequence, var_len_array, ... Number of all sorts hash, associated containers keep appearing all the time. People inventing new containers. While policy-based solution would(could) fit to majority cases. I still hope that policy-based container will find it's way to standard (or in boost at least) at some time soon.

Typedef et al add a protective shield from complexity, and that's indeed a strong argument - "you can still use shared_ptr (or equivalent) as with the current interface/implementation in Boost". Sure. At least sometimes. If I do, the policies will have bought me nothing. If I don't, I've gone beyond compatibility (type and binary) with those typedef'ed smart pointers anyway. It's back to roll-your-own, but now with policies rather than the whole ball-of-smart-pointer.

Many users will use typedefs and do not bother how it was implemented (shared implementation gives you unified interface and some confidence that everything will work only). While advanced users will use framework to easily create custom containers. So policy-based solution works for everybody(most of the users).

Bjorn "sorry for speaking although I didn't attend" Karlsson

Regards,
 
Gennadiy.