Re: [boost] [intrusive] Interface for hooking into client code improvable?

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.

Regards,

Ion