Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2022-09-22 21:31:37


Frank Mori Hess wrote:
> On Thu, Sep 22, 2022 at 8:57 AM Peter Dimov <pdimov_at_[hidden]> wrote:
> >
> > That's complete nonsense. First, Microsoft invented __forceinline, so
> > making BOOST_FORCEINLINE be a no-op on the very compiler for which the
> > feature has been added would be ridiculous. Second, it does force
> > inlining, that's why it's called __forceinline. The whole point of the
> > warning is to warn about the rare cases where the compiler does not
> > honor the command; it exists because people want to know whether their
> > "force inline" orders are ignored.
>
> But no boost user wants to be warned about some internal implementation
> detail of a boost library.

Yes of course. But users do want to be warned about their own code. And if
Boost.Config disables the warning, they won't be, even if they don't use
variant at all.

> Who is the maintainer of variant anyways?

Antony Polukhin, I believe.

https://github.com/boostorg/boost/blob/80e75653fcd6b9ad145f9a103d5c5a592a221c90/libs/maintainers.txt#L173

Note by the way that MSVC honors the #pragma warning even if it's applied
locally around the __forceinline function: https://godbolt.org/z/sW99TYa66

So the variant header can do this, without affecting other uses.

Is there an issue in boostorg/variant about this problem?


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk