[variant] 'which' out of range assertion
Hello,
It appears that since 1.47 Boost.Variant has a bug that can be
reproduced as follows (MSVC10, Debug mode):
#include
::type vec_type; typedef boost::make_variant_over
::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-ele... It seems that the above issue is somehow related to this change. Igor'.
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
Hello,
It appears that since 1.47 Boost.Variant has a bug that can be reproduced as follows (MSVC10, Debug mode):
#include
#include 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
::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-ele... It seems that the above issue is somehow related to this change.
Igor'. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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!
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?
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
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? _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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-siz...
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
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-siz... _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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.
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
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. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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.
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
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. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
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-ele... 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
participants (3)
-
Daniel Bradburn -
Igor R -
Steven Watanabe