Re: [boost] Standalone boost::ignore_unused_variable_warning()

Subject: Re: [boost] Standalone boost::ignore_unused_variable_warning()
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-05-19 09:58:42

Hi,

2014-05-19 3:58 GMT+02:00 Matt Calabrese <rivorus_at_[hidden]>:

> On Sun, May 18, 2014 at 5:56 AM, Adam Wulkiewicz
> <adam.wulkiewicz_at_[hidden]>wrote:
>
> > And finally I'm considering adding similar tool for unused typedefs
> > because some compilers (GCC4.8) warns about them and there are cases,
> e.g.
> > when some part of code is shielded with some #ifdef, where they can't be
> > commented out or removed. E.g. something like this would work, though I'm
> > not sure if there is no better way, so I'm open to suggestion.
> >
>
> I support these going in, though I have a suggestion for the unused typedef
> warning -- you may want to be able to do this outside of a function
> definition (I.E. at global scope or in a class's body). For situations like
> this, I often find that using a static_assert may be better than an
> expression, as it can be written almost anywhere. In other words, something
> along the lines of:
>
> /////
> static_assert( ignore_unused_typedef< T1, T2 >::value, "This will never
> fire." );
> /////
>
> where the ignore_unused_typedef metafunction is basically just an
> always_true metafunction. In other words, I suggest you simply have it
> inherit from std::true_type or boost::mpl::true_. A macro alias that hides
> the static_assert and unseen message may also be beneficial.
>

Thanks for the suggestion!
I also like the idea of a macro which could be put anywhere and only take
types as parameters.
There are some problems with the above example but this gave me an idea.
The types could be passed as a parenthized list:

BOOST_IGNORE_UNUSED_TYPEDEF_WARNING((T1, T2, T3));

then internally used e.g. to build some function type or just passed to the
BOOST_MPL_ASSERT_MSG as the last parameter.

So as a reminder the other approach is:

ignore_unused_typedef_warning<T1, T2, T3>();

Any other ideas?

Regards,
Adam