Opened 12 years ago

Last modified 12 years ago

#4666 new Bugs

boost::variant gives several warnings (fix suggestions included)

Reported by: Lieven de Cock <killerbot@…> Owned by: Aleksey Gurtovoy
Milestone: To Be Determined Component: mpl
Version: Boost 1.44.0 Severity: Cosmetic
Keywords: Cc:

Description

I am using several compiler options with gcc to increase the warning level. Especially 3 of them are raising warnings :

1) -Wshadow Too warn when a variable is shadowing/hiding another variable/method This occurs in boostvariant/variant.hpp

void indicate_which(int which)
    {
        which_ = static_cast<which_t>( which );
    }

    void indicate_backup_which(int which)
    {
        which_ = static_cast<which_t>( -(which + 1) );
    }

the local which is shadowing the member method which.

My suggestion to fix would be :

    void indicate_which(int which_in)
    {
        which_ = static_cast<which_t>( which_in );
    }

    void indicate_backup_which(int which_in)
    {
        which_ = static_cast<which_t>( -(which_in + 1) );
    }

So I just renamed to local to which_in

2) -Wswitch-default warn when a switch statement doesn't have a default case. This occurs at : boost/variant/detail/visitation_impl.hpp

    // ...switch on the target which-index value...
    switch (logical_which)
    {

    // ...applying the appropriate case:
#   define BOOST_VARIANT_AUX_APPLY_VISITOR_STEP_CASE(z, N, _) \
    case (Which::value + (N)): \
        return visitation_impl_invoke( \
              internal_which, visitor, storage \
            , static_cast<BOOST_PP_CAT(T,N)*>(0) \
            , no_backup_flag, 1L \
            ); \
    /**/

    BOOST_PP_REPEAT(
          BOOST_VARIANT_VISITATION_UNROLLING_LIMIT
        , BOOST_VARIANT_AUX_APPLY_VISITOR_STEP_CASE
        , _
        )

#   undef BOOST_VARIANT_AUX_APPLY_VISITOR_STEP_CASE

    }

My suggestion is to add the following just in front of the end brace of the switch :

    default: break;

3) -Wundef warns if an undefined identifier is evaluated in an #if directive This occurs at : boost/mpl/has_xxx.hpp It occurs 4 times (that I ran into, within all the ifdef stuff it might occur a few times more).

#   if !BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION
#     define BOOST_MPL_HAS_MEMBER_REJECT(args, member_macro) \
        template< typename V > \
        static boost::mpl::aux::no_tag \
        BOOST_MPL_HAS_MEMBER_INTROSPECTION_TEST_NAME(args)(...); \
      /**/
#   else
#     define BOOST_MPL_HAS_MEMBER_REJECT(args, member_macro) \
        static boost::mpl::aux::no_tag \
        BOOST_MPL_HAS_MEMBER_INTROSPECTION_TEST_NAME(args)(...); \
      /**/
#   endif

The question is : BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION, does it need to have a special value (for example : not 0), or is it just a matter of beind defined or not. In the latter case, this are my suggestions on how to fix :

line 344 --> # if not defined (BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION) line 357 --> # if not defined (BOOST_MPL_HAS_XXX_NO_WRAPPED_TYPES) line 386 --> # if not defined (BOOST_MPL_HAS_XXX_NO_EXPLICIT_TEST_FUNCTION) line 458 --> # if defined (BOOST_MPL_HAS_XXX_NEEDS_TEMPLATE_SFINAE)

What do you think ?

kind regards, Lieven

Change History (1)

comment:1 by Steven Watanabe, 12 years ago

Component: variantmpl
Owner: changed from ebf to Aleksey Gurtovoy

I addressed the warnings from variant in [71083]. Reassigning to MPL for the last one.

Note: See TracTickets for help on using tickets.