Tobias Schwinger wrote:
The only potential problem I see is that
container< a_policy, another_policy >
and
container< another_policy, a_policy >
are distinct types and some compiler might not factor out redundant code properly. It can be dealt with in two ways:
This is quite frightening to me. There is another way to minimize bloat: typedef define_container< another_policy, a_policy >::type Container; The combination is concentrated in the auxiliary define_container but the resulting container is exactly the same. But it's not as easy to use as the straight policy approach. Another question is that Intrusive has already received a review, and such important breaking change would need at least consensus from Boosters.
But I agree that so many options might confuse users. Maybe a configuration structure might be better:
struct options { //If not present, defaults to true static const bool contant_time_size = true;
//If not present, defaults to std::size_t typedef unsigned short size_type;
//... };
list<T, options>
Yes, much better.
This option has also the problem of instantiating different containers with the same options, just because "options" will be a user type. Another approach can be: list<T, list_options<Policy1, Policy2, Policy3>::type> where the created type is unique type even if policies are passed in different order, because list_options does the job of creating a unique options type for the same policies. The question is if the use of policies will simplify the life of the average programmer or if specifying "normal" (meaning raw) template parameters will be easier. Regards, Ion