Problems with MPL in Fusion on MSVC 6.5
Hi. I am porting Fusion, Joel de Guzmans new tuple library to MSVC 6.5 and VC 7.0. Several of the testcases ICEs on MSVC 6.5. I traced the problems back to integral_c's operator int() Problem: When the template expressions gets too complicated, MSVC is unable to handle inlined functions inside a type computer struct. Solution: Place the function body outside of the struct. The relevant lines: operator AUX_WRAPPER_VALUE_TYPE() const #if BOOST_WORKAROUND(BOOST_MSVC,==1200) ; #else { return static_cast<AUX_WRAPPER_VALUE_TYPE>(this->value); } #endif }; #if BOOST_WORKAROUND(BOOST_MSVC,==1200) template< AUX_WRAPPER_PARAMS(N) > AUX_WRAPPER_INST(N)::operator AUX_WRAPPER_VALUE_TYPE() const { return static_cast<AUX_WRAPPER_VALUE_TYPE>(this->value); } #endif This change fixed most of the remaining (known) issues with Fusion & MSVC Is it OK if I check in these changes? -- Peder Holt
Peder Holt writes:
Hi. I am porting Fusion, Joel de Guzmans new tuple library to MSVC 6.5 and VC 7.0. Several of the testcases ICEs on MSVC 6.5. I traced the problems back to integral_c's operator int() Problem: When the template expressions gets too complicated, MSVC is unable to handle inlined functions inside a type computer struct. Solution: Place the function body outside of the struct.
The relevant lines: operator AUX_WRAPPER_VALUE_TYPE() const #if BOOST_WORKAROUND(BOOST_MSVC,==1200) ; #else { return static_cast<AUX_WRAPPER_VALUE_TYPE>(this->value); } #endif };
#if BOOST_WORKAROUND(BOOST_MSVC,==1200) template< AUX_WRAPPER_PARAMS(N) > AUX_WRAPPER_INST(N)::operator AUX_WRAPPER_VALUE_TYPE() const { return static_cast<AUX_WRAPPER_VALUE_TYPE>(this->value); } #endif
This change fixed most of the remaining (known) issues with Fusion & MSVC Is it OK if I check in these changes?
If it doesn't break "libs/mpl/test/int.cpp" and "libs/mpl/test/for_each.cpp" tests, go ahead. -- Aleksey Gurtovoy MetaCommunications Engineering
On Fri, 6 Aug 2004 05:52:20 -0500, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
Peder Holt writes:
Hi. I am porting Fusion, Joel de Guzmans new tuple library to MSVC 6.5 and VC 7.0. Several of the testcases ICEs on MSVC 6.5. I traced the problems back to integral_c's operator int() Problem: When the template expressions gets too complicated, MSVC is unable to handle inlined functions inside a type computer struct. Solution: Place the function body outside of the struct.
The relevant lines: operator AUX_WRAPPER_VALUE_TYPE() const #if BOOST_WORKAROUND(BOOST_MSVC,==1200) ; #else { return static_cast<AUX_WRAPPER_VALUE_TYPE>(this->value); } #endif };
#if BOOST_WORKAROUND(BOOST_MSVC,==1200) template< AUX_WRAPPER_PARAMS(N) > AUX_WRAPPER_INST(N)::operator AUX_WRAPPER_VALUE_TYPE() const { return static_cast<AUX_WRAPPER_VALUE_TYPE>(this->value); } #endif
This change fixed most of the remaining (known) issues with Fusion & MSVC Is it OK if I check in these changes?
If it doesn't break "libs/mpl/test/int.cpp" and "libs/mpl/test/for_each.cpp" tests, go ahead.
It turns out that both versions of the source causes VC 6.5 to ICE. When used as a type computer, my version of the source is the best choice. When using an integral_c<int,N> as a variable representing an int, your version is the best choice. I ended up implementing a local tailor made version of int_ that I used where the type compute approach was needed. -- Peder Holt
-- Aleksey Gurtovoy MetaCommunications Engineering
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Peder Holt <peder.holt@gmail.com> writes:
It turns out that both versions of the source causes VC 6.5 to ICE. When used as a type computer, my version of the source is the best choice. When using an integral_c<int,N> as a variable representing an int, your version is the best choice.
I ended up implementing a local tailor made version of int_ that I used where the type compute approach was needed.
Can you get the ICE to go away by pushing the operator into a base class? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Peder Holt wrote:
It turns out that both versions of the source causes VC 6.5 to ICE. When used as a type computer, my version of the source is the best choice. When using an integral_c<int,N> as a variable representing an int, your version is the best choice.
I ended up implementing a local tailor made version of int_ that I used where the type compute approach was needed.
I don't know if this is what's causing your ICE, but it reminds me of a VC 6.5 bug I found a while ago for classes with int template parameters. The attached file causes an ICE, which can be prevented by uncommenting the class 'dummy'. At least, that's what happens for me. It's possible to trigger this ICE by including some boost headers in a specific, and slightly odd, order (sorry, I forget which headers). So, you might find that adding a class, with a member function, immediately before integral_c will stop the ICE. If so, it might be worth adding this workaround to all such classes. Although, I'm not really sure about this, since it's very odd. Daniel
participants (4)
-
Aleksey Gurtovoy -
Daniel James -
David Abrahams -
Peder Holt