On Sun, Mar 2, 2014 at 3:24 AM, Jon Biggar wrote:

I'm guessing that putting the correct enable_if<> template constraints on the templates that use 'ForwardRange' will fix the issue, but I'm having trouble identifing the correct metafunction test to use, since concept FowardRange concept doesn't have too many good targets.

Making the constructor overloads less greedy is definitely an improvement. This has been implemented and pushed to the "develop" branch.

I'd like to test a candidate FowardRange type to see if boost::begin() and boost::end() can be successfully called on it, but I haven't figured out how to do that yet.

Any suggestions? Known fixes or workarounds? I know about the has_range_iterator metafunction, but it can't be used here due to circular definition issues...

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.

Exmaple:

#include #include #include

using namespace boost;

enum E { e1, e2, e3 };

typedef mpl::vector args; typedef boost::make_variant_over<args>::type OkVariant;

typedef mpl::vectorstd::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_rangestd::string::iterator >::type args1;

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. This therefore probably now works with "develop", but it is not going to be super-portable. If old compilers are not important to you it would be entirely reasonable to ignore this consideration.

-- Jon Biggar jon@floorboard.com jon@biggar.org jonbiggar@gmail.com

If you have time to try out the "develop" branch then please let me know how you get on with it. Thanks for reporting the issue. I hope these changes help. Regards, Neil Groves