Boost logo

Boost :

Subject: Re: [boost] boost::iterator_range does not work in boost::variant in boost 1.55
From: Jon Biggar (jon_at_[hidden])
Date: 2014-03-11 02:21:58

On 3/2/14, 3:01 PM, Neil Groves wrote:
>> Making the constructor overloads less greedy is definitely an improvement.
> This has been implemented and pushed to the "develop" branch.

Good, I did it also in my own copy, using the SInglePassRangeConcept and
WriteableRangeConcept from boost/range/concept.hpp, for both the
constructors and the assignment operators. It seems to help a lot.

>> I has to modify your test case in a number of ways to be able to reproduce
> the problem accurately without artificial breakage. Hopefully my changes to
> make your test-case work did not remove any of the conditions you were
> attempting to demonstrate.

I expected that. :) I'm still pretty new to mpl.

>> Exmaple:
>> #include <boost/variant.hpp>
>> #include <boost/range.hpp>
>> #include <boost/mpl/vector.hpp>
>> using namespace boost;
>> enum E {
>> e1, e2, e3
>> };
>> typedef mpl::vector<E, std::string > args;
>> typedef boost::make_variant_over<args>::type OkVariant;
>> typedef mpl::vector<boost::iterator_range<std::string::iterator>, args>
>> args1;
> args1 is not what you want for passing into the make_variant_over function
> since it is not an extended sequence as I think you intended. You need to
> do this:
> typedef boost::mpl::push_back<
> args, boost::iterator_range<std::string::iterator> >::type args1;

Yup, discovered that a day or two after posting, thanks.

>> typedef boost::make_variant_over<args1>::type BrokenVariant;
>> int main(int argc, char **argv)
>> {
>> OkVariant ok;
>> ok = e1;
>> ok = "";
> Your expression "" is of type const char[1]. Depending on the compiler this
> might match overloads for char* due to old rules allowing interopability
> between string literals and mutable char pointers and arrays. It is valid
> for a standard library implementation to implement the
> std::string::iterator as char*. If all these factors conspire against you
> then even with the updates in the "develop" branch you will suffer
> ambiguous function calls.

Ah, true. I've fallen into the problem that template argument deduction
doesn't work like function overloading resolution...there's no use or
ranking of conversions.

I've learned a lot in the last week or too, and moved past this trouble.
  Thanks for your help.

Jon Biggar

Boost list run by bdawes at, gregod at, cpdaniel at, john at