
I am getting an annoying warning when building boost_math.dll AND generating Microsoft VS 8.0 'managed' code /clr:pure, even at warning level 1. (clr code is needed because we are building a Windows .net form in C# to demonstrate Math function and Statistics Distribution using John Maddock's Math Toolkit in C++. Aside - with a lot of annoying wrapping, John has made this work). The message is: C4793 'vararg' : causes native code generation for function 'void boost::detail::sp_enable_shared_from_this(const boost::detail::shared_count &,...)' Adding this #pragma to the top of our boost_math.cpp file does NOT suppress it. #pragma warning(disable: 4793) // 'vararg' : causes native code generation for function 'void boost::detail::sp_enable_shared_from_this(const boost::detail::shared_count &,...)' Is this worrying? Is there something wrong with the pushing and popping of warnings? Someone has already done some message suppression for SGI I see. #ifdef sgi // Turn off: the last argument of the varargs function "sp_enable_shared_from_this" is unnamed # pragma set woff 3506 #endif Is this the right way to deal with it for MSVC in shared_prt.hpp? #ifdef _MSC_VER #pragma warning(push) #pragma warning(disable: 4793) // 'vararg' : causes native code generation for function 'void boost::detail::sp_enable_shared_from_this(const boost::detail::shared_count &,...)' #endif inline void sp_enable_shared_from_this( shared_count const & /*pn*/, ... ) { } #ifdef sgi # pragma reset woff 3506 #endif #ifdef _MSC_VER #pragma warning(pop) #endif With this it gives a clean compile :-)) Could/should this is added to the normal Boost shared_prt.hpp? Or is there a cleaner solution that avoids vararg? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com

Paul A Bristow wrote:
If you compile with /clr:pure, you presumably don't want native functions in your assembly, so the warning is legitimate (unless the optimizer is smart enough to see that the function is empty and not include it in the assembly). Avoiding the ... isn't as trivial as it appears. You might want to try replacing inline void sp_enable_shared_from_this( shared_count const & /*pn*/, ... ) { } with struct sp_any_pointer { template<class T> sp_any_pointer( T* ) {} }; inline void sp_enable_shared_from_this( shared_count const & /*pn*/, sp_any_pointer, sp_any_pointer ) { } for the _MANAGED case and see if it helps.

I don't want this native function - and I don't believe I am using it, so I presume the optimizer isn't smart enough to see that... This works OK for me: #ifdef _MANAGED // C4793) // 'vararg' : causes native code generation for function 'void boost::detail::sp_enable_shared_from_this(const boost::detail::shared_count &,...)' // Avoid using vararg ... with a dummy. struct sp_any_pointer { template<class T> sp_any_pointer( T* ) {} }; inline void sp_enable_shared_from_this( shared_count const & /*pn*/, sp_any_pointer, sp_any_pointer ) { } #else // NOT managed. #ifdef sgi // Turn off: the last argument of the varargs function "sp_enable_shared_from_this" is unnamed # pragma set woff 3506 #endif inline void sp_enable_shared_from_this( shared_count const & /*pn*/, ... ) { } #ifdef sgi # pragma reset woff 3506 #endif #endif // _MANAGED So this looks much better than quieting the warning. I have presumed that SGI won't generate this warning if it manages to produce managed code (and defines _MANAGED macro)? Many thanks. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
participants (2)
-
Paul A Bristow
-
Peter Dimov