Boost logo

Boost :

Subject: [boost] Nonstandard instantiation of std::initializer_list
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2011-02-03 03:35:41


Hi,

I'm working on a factory generator tool and I would like
to support types with initializer-list constructors, typically
containers. There are several possibilities how to do this,
but the otherwise most straightforward and generic way,
requires non-standard construction of std::initializer_list<T>
instances.

I have the following working implementation for GCC
(a complete, very simplified example showing the usage
that can be compiled with g++ 4.5 with --std=c++0x is
in the attachment):

template <typename Element>
class initializer_list_holder
{
private:
    typename std::initializer_list<Element>::iterator data;
    typename std::initializer_list<Element>::size_type size;
    std::vector<Element> elems;

    void init(void)
    {
        data = elems.data();
        size = elems.size();
    }
public:
    initializer_list_holder(std::vector<Element>&& tmp)
     : elems(std::move(tmp))
    {
        init();
    }

    template <typename StdRange>
    initializer_list_holder(const StdRange& src)
     : elems(src.begin(), src.end())
    {
        init();
    }

    operator std::initializer_list<Element>() const
    {
        return reinterpret_cast<
            std::initializer_list<Element> const &
>(*this);
    }
};

The template above stores the elements to be traversed
by the initializer-list's iterators in a vector and depends
on the GCC's implementation of the initializer_list. The plan
is to do something similar for other implementations of
initializer_list by other compilers and switch between them
via the preprocessor.

(Yes, I know that vector<T>::data() is a non-standard extension,
and on platforms where it is not available the array of elements
would be managed directly by the initializer_list_holder)

My questions are:
Is this is good idea ?
Do you foresee some reason for any compiler to use another
implementation of std::initializer_list, besides the "obvious"
listed in n2672 (pair of pointers / pointer + size), that wouldn't
work with the reinterpret_cast in the conversion operator ?
Should I look at the other possibilities to implement the factory?

TIA for your insights.

Best,

Matus




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