|
Boost Users : |
From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2008-08-20 06:26:47
Joel de Guzman <joel <at> boost-consulting.com> writes:
> Fixed. I admit it's a bug. The thing is, fusion tuple adopted the
> TR1 interface in essence plus some more extensions to take advantage
> of the features fusion provides beyond TR1 (e.g. iterators, algorithms,
> sequence compatibility, etc.). The side effect is that corner cases
> like this becomes problematic on some compilers.
>
> Solution: conform to TR1 to the letter. No extras. No more, no less.
> The downside is that some features (e.g. copy/assign from a fusion
> list or view) are *now disabled*. Anyway, if you want a more feature
> rich implementation, go for the fusion vector.
And this here fails:
#include <boost/assign/list_of.hpp>
#include <boost/assign/list_inserter.hpp>
#include <boost/tr1/tuple.hpp>
#include <list>
int main(int argc, char* argv[])
{
typedef std::list<std::tr1::tuple<int, std::string> > mod_list_t;
static mod_list_t const l =
boost::assign::tuple_list_of(1, "A")(2, "B");
return 0;
}
Any hint?
Markus
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net