Re: [Boost-users] [signals2][variant] inline warning with MSVC 2022

Peter Dimov via Boost <[email protected]>
Newsgroups gmane.comp.lib.boost.devel,gmane.comp.lib.boost.user
Message-ID <[email protected]>
Frank Mori Hess wrote:
> On Thu, Sep 22, 2022 at 8:57 AM Peter Dimov <[email protected]> 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?



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.