[Boost-users] [variant] 'which' out of range assertion

[Igor R]

Hello,

It appears that since 1.47 Boost.Variant has a bug that can be
reproduced as follows (MSVC10, Debug mode):

#include <boost/variant.hpp>
#include <boost/mpl/vector/vector30.hpp>

struct struct1{};
struct struct2{};
struct struct3{};
struct struct4{};
struct struct5{};
struct struct6{};
struct struct7{};
struct struct8{};
struct struct9{};
struct struct10{};
struct struct11{};
struct struct12{};
struct struct13{};
struct struct14{};
struct struct15{};
struct struct16{};
struct struct17{};
struct struct18{};
struct struct19{};
struct struct20{};
struct struct21{};

typedef boost::mpl::vector21<
struct1,
struct2,
struct3,
struct4,
struct5,
struct6,
struct7,
struct8,
struct9,
struct10,
struct11,
struct12,
struct13,
struct14,
struct15,
struct16,
struct17,
struct18,
struct19,
struct20,
struct21
>::type vec_type;
typedef boost::make_variant_over<vec_type>::type var_type;

int main()
{
var_type v;
v = struct21();
}

The last line generates assertion in variant_impl.hpp, line 264,
visitation_impl() function: "Boost.Variant internal error: 'which' out
of range."

According to the release notes, variant wasn't changed in 1.47, but I
recalled teh following discussion:
http://boost.2283326.n4.nabble.com/large-variant-performance-compared-50-elements-tt3204484.html#a3205490
It seems that the above issue is somehow related to this change.

Igor'.
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Daniel Bradburn]

Hi Igor,

You can get around this by increasing the maximum size a variant can handle, define the following symbols (or higher if you need):

#define BOOST_MPL_LIMIT_LIST_SIZE 30

#define BOOST_MPL_LIMIT_VECTOR_SIZE 30

#define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS

And it should work again.

Regards

Dan

2012/2/22 Igor R <boost...@gmail.com>

[Igor R]

> You can get around this by increasing the maximum size a variant can handle,
> define the following symbols (or higher if you need):
>
> #define BOOST_MPL_LIMIT_LIST_SIZE 30
> #define BOOST_MPL_LIMIT_VECTOR_SIZE 30
> #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS
>
> And it should work again.

Oh, I see...
But anyway, if I went beyond the limit, shouldn't it produce some
compile-time error, rather than failng in runtime in such a weird way
in debug mode only?

Thanks!

[Igor R]

>> You can get around this by increasing the maximum size a variant can handle,
>> define the following symbols (or higher if you need):
>>
>> #define BOOST_MPL_LIMIT_LIST_SIZE 30
>> #define BOOST_MPL_LIMIT_VECTOR_SIZE 30
>> #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS

And one more question: if I define these macros in some TU of my
project, in the way that affects some other boost headers I include --
should I define them when building boost as well?

[Daniel Bradburn]

I agree, it would be much better if this was picked up at compile time - took a while searching and head scratching before I figured out what the problem was.

I found that it was not necessary to define these when building boost, but I'm not 100% sure whether that is necessary, I think that depends on which non-header only library use these macros, perhaps you could do a quick search of the boost directory just to make sure.

2012/2/22 Igor R <boost...@gmail.com>

[Igor R]

> I agree, it would be much better if this was picked up at compile time -
> took a while searching and head scratching before I figured out what the
> problem was.

Yes, that's really strange, because the documentation says that these
macros affect variadic forms of the sequences, while I use the fixed
ones.
http://www.boost.org/doc/libs/1_48_0/libs/mpl/doc/refmanual/limit-vector-size.html

[Daniel Bradburn]

Although it affects the variadic form of the mpl containers, the limit for variant types is set from the BOOST_MPL_LIMIT_LIST_SIZE macro.

2012/2/22 Igor R <boost...@gmail.com>

[Igor R]

> Although it affects the variadic form of the mpl containers, the limit for
> variant types is set from the BOOST_MPL_LIMIT_LIST_SIZE macro.

Take a look at this thread:
http://lists.boost.org/boost-users/2008/05/36488.php

So, despite the workaround you found, it seems to be a bug.

[Daniel Bradburn]

I don't see anything in that thread that suggests this is a bug. I think Steve's statement that the limitation can be worked around by using make_variant_over is no longer valid, since some pretty crucial variant visitation code uses preprocessor metaprogramming and BOOST_VARIANT_LIMIT_SIZE is central to this (take a look at BOOST_VARIANT_VISITATION_UNROLLING_LIMIT in visitation_impl.hpp). Perhaps this is something new since that thread (2008) - however I don't see anything in the release notes from 145 to 147 which would suggest that something changed here (145 is the version I upgraded from when this last worked for me). It may be possible to just define BOOST_VARIANT_VISITATION_UNROLLING_LIMIT and get the desired effect.

2012/2/22 Igor R <boost...@gmail.com>

[Igor R]

> I don't see anything in that thread that suggests this is a bug. I think
> Steve's statement that the limitation can be worked around by using
> make_variant_over is no longer valid

...and this is the bug (i.e. undesired behavior), isn't it.

> since some pretty crucial variant
> visitation code uses preprocessor metaprogramming and
> BOOST_VARIANT_LIMIT_SIZE is central to this (take a look at
> BOOST_VARIANT_VISITATION_UNROLLING_LIMIT in visitation_impl.hpp). Perhaps
> this is something new since that thread (2008) - however I don't see
> anything in the release notes from 145 to 147 which would suggest that
> something changed here (145 is the version I upgraded from when this last
> worked for me).

Yes, that's what I wrote in the original post (see the link there):
some optimization was made in 1.46, it was not reflected in the
release notes, and I guess this change caused the issue we're talking
about.
Maybe Steven could shed some light on this.

[Daniel Bradburn]

I'd categorise it as a breaking change, not a bug. But perhaps that's just semantics. In any case it would have been nice to have seen it in the release notes. But I don't really understand the problem if you can control the behaviour through a macro? Personally I'd rather have the more optimal code.

2012/2/22 Igor R <boost...@gmail.com>

[Steven Watanabe]

AMDG

On 02/22/2012 07:25 AM, Igor R wrote:
> It appears that since 1.47 Boost.Variant has a bug that can be
> reproduced as follows (MSVC10, Debug mode):
>

> <snip>

> The last line generates assertion in variant_impl.hpp, line 264,
> visitation_impl() function: "Boost.Variant internal error: 'which' out
> of range."
>
> According to the release notes, variant wasn't changed in 1.47, but I
> recalled teh following discussion:
> http://boost.2283326.n4.nabble.com/large-variant-performance-compared-50-elements-tt3204484.html#a3205490
> It seems that the above issue is somehow related to this change.
>

It's unrelated. The problem was introduced in

r71083 | steven_watanabe | 2011-04-07 08:35:56 -0700 (Thu, 07 Apr 2011)
| 1 line

Supress warnings from variant. Refs #4666.

I just fixed this in r77098

In Christ,
Steven Watanabe

[Igor R]

> It's unrelated.  The problem was introduced in
>
> r71083 | steven_watanabe | 2011-04-07 08:35:56 -0700 (Thu, 07 Apr 2011)
> | 1 line
>
> Supress warnings from variant.  Refs #4666.
>
> I just fixed this in r77098

Great,

Thanks!