Boost logo

Boost :

Subject: Re: [boost] boost::iterator_range does not work in boost::variant in boost 1.55
From: Neil Groves (neil_at_[hidden])
Date: 2014-03-02 18:01:55


On Sun, Mar 2, 2014 at 3:24 AM, Jon Biggar <jon_at_[hidden]> 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 <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;

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk