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