Re: [boost] boost::iterator_range does not work in boost::variant in boost 1.55

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
jon_at_[hidden]
jon_at_[hidden]
jonbiggar_at_[hidden]