From: "David Abrahams" <dave@boost-consulting.com>
Terje Slettebø <tslettebo@broadpark.no> writes:
From: "Terje Slettebø" <tslettebo@broadpark.no>
This way, we get:
copy<c_list>(std::back_inserter(r_list));
Output of a compile-time sequence is also trivial:
copy<c_list>(std::ostream_iterator<int>(std::cout,","));
Thinking about this some more, the only reason this works is that the sequence consists of elements of the same type (integral_c derived), and that it has an implicit conversion to the value type.
However, it would also be possible to support heterogenous sequences, but then, the standard iterator adapters aren't sufficient, as they only work for homogenous sequences. That's possible to make, though.
For fun, I knocked up this program, which stores values of a variety of types in a compile-time sequence (char, int, double, rational_c and std::string (wrapped)), prints the sequence out, copies it to a run-time sequence (using boost::variant as element type), and prints it out, again.
You seem to be treading heavily into the territory of boost::fusion here, no?
That's hard to tell, given that there's hardly any docs on boost::fusion (however, the library was on my mind when I mentioned "fusion of compile-time and run-time" in an earlier posting, since that says in fusion's docs. I didn't think this was anybody's territory in particular, though (it seems very broad)). However, looking at the fusion docs, again, it seems you're right. What I had originally thought about, was MPL (where this thread originated). However, as you say, boost::fusion might be more appropriate for it. The above was only meant for inspiration and fun. If this functionality, or something like it, already exists in boost::fusion, then great. However, complaining about me treading into another library's territory, when I haven't found any fence (docs, showing me that this exist already), seems a bit unfair. (Maybe it wasn't meant as complaint, but it seemed that way. If you had just mentioned that this exists in boost::fusion, or it may be more appropriate for it, I wouldn't had a problem with it.) Regards, Terje