Boost logo

Boost :

From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2007-08-10 05:07:39

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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at