Boost logo

Boost :

Subject: Re: [boost] [container] varray aka static_vector
From: Krzysztof Czainski (1czajnik_at_[hidden])
Date: 2013-02-12 10:17:55


2013/2/11 Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]>

> Krzysztof Czainski wrote:
>
> I assume I can't change the Strategy or emplace_back()/resize() behavior
>> for just one particular varray object, can I?
>>
>> I mean:
>>
>> varray<int,5> a;
>> varray<int,5> b;
>>
>> I'd like to change the Strategy only for b, can I do that?
>>
>
> You may do it by partially specialize varray_traits for your strategy.
> Currently the varray allowing to pass user-defined strategy is implemented
> in the container_detail namespace. So it would look more or less like this:
>
> namespace bc = boost::container;
>
> // define my strategy
> template <typename V>
> struct my_strategy : public bc::container_detail::**strategy::def<V> {};
>
> // specialize traits for my strategy
> namespace boost { namespace container { namespace container_detail {
>
> template <typename V, typename C>
> struct varray_traits<V, C, my_strategy>
> : public varray_traits<V, C, strategy::def<V> >
> {
> typedef boost::true_type disable_trivial_init;
> };
>
> }}}
>
> /*...*/
>
> // use non-default version of varray
> bc::container_detail::varray<**int, 5, my_strategy<int> > b;
>

Aha, so I just use the hidden in container_detail version of varray with 3
template parameters.

Future alternative:
>
> Currently settings like disable_trivial_init are hidden deeply inside
> details. However they might be a part of default Strategy concept. Assuming
> that varray was moved to the boost::container namespace the example would
> be shorter:
>
> // define my strategy
> template <typename V>
> struct my_strategy : public bc::strategy::def<V>
> {
> typedef boost::true_type disable_trivial_init;
> };
>
> /*...*/
>
> // use non-default version of varray
> bc::varray<int, 5, my_strategy<int> > b;
>

Ok, then +1 for this option ;-)

Thank you, Adam, for elaborating on this topic.

Cheers,
Kris


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk