$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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