Boost C++ Libraries: Ticket #10215: Defaulted functions not fully supported in VC 2013 https://svn.boost.org/trac10/ticket/10215 <p> Hi all, Visual C++ 2013 has only partial support for defaulted functions: h t t p : / / m s d n . m i c r o s o f t . c o m / e n - u s / l i b r a r y / h h 4 0 9 2 9 3 . a s p x </p> <p> I received the following error while running bjam with Visual Studio 2013 (but see further down for successful resolution): </p> <p> bjam --with-python python-debugging=off threading=multi variant=release link=shared address-model=64 toolset=msvc-12.0 stage </p> <p> --- hopefully irrelevant parts removed --- </p> <p> .\boost/graph/detail/adjacency_list.hpp(298) : error C2610: 'boost::detail::stored_edge_property&lt;Vertex,Property&gt;::stored_edge_property(boost::detail::stored_edge_property&lt;Vertex,Property&gt; &amp;&amp;)' : is not a special member function which can be defaulted </p> <blockquote> <p> .\boost/graph/detail/adjacency_list.hpp(304) : see reference to class template instantiation 'boost::detail::stored_edge_property&lt;Vertex,Property&gt;' being compiled </p> </blockquote> <hr /> <p> I then defined BOOST_NO_CXX_DEFAULTED_FUNCTIONS in boost/config/compilers/visualc.hpp and it appears that everything has compiled successfully. Perhaps there could be more fine-grained support for what VC 2013 supports and doesn't, but for me, it's not relevant, so here is my patch: </p> <p> Index: visualc.hpp =================================================================== --- visualc.hpp (revision 86799) +++ visualc.hpp (working copy) @@ -171,7 +171,6 @@ </p> <blockquote> <p> <em> C++11 features supported by VC++ 12 (aka 2013). </em> #if _MSC_FULL_VER &lt; 180020827 </p> </blockquote> <p> -# define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS </p> <blockquote> <p> # define BOOST_NO_CXX11_DELETED_FUNCTIONS # define BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS # define BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS </p> </blockquote> <p> @@ -194,6 +193,12 @@ </p> <blockquote> <p> #define BOOST_NO_CXX11_USER_DEFINED_LITERALS #define BOOST_NO_CXX11_ALIGNAS #define BOOST_NO_CXX11_INLINE_NAMESPACES </p> </blockquote> <p> +<em> +</em> Although VC 2013 claims to support defaulted functions, it +<em> does not support the =default construct. See +</em> h t t p : / / m s d n . m i c r o s o f t . c o m / e n - u s / l i b r a r y / h h 4 0 9 2 9 3 . a s p x +<em> +#define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS </em></p> <blockquote> <p> <em> </em> prefix and suffix headers: </p> </blockquote> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/10215 Trac 1.4.3 leek@… Fri, 18 Jul 2014 13:44:16 GMT attachment set https://svn.boost.org/trac10/ticket/10215 https://svn.boost.org/trac10/ticket/10215 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">visualc.hpp.diff</span> </li> </ul> <p> Patch to visualc.hpp </p> Ticket bdavis@… Tue, 02 Dec 2014 22:07:58 GMT <link>https://svn.boost.org/trac10/ticket/10215#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10215#comment:1</guid> <description> <p> I'm encountering this as well. The OpenGL wrapper library Oglplus has the option to use Boost Config instead of an empirical testing step, but boost config reports defaulted functions supported on VS 2013, even though there's only partial support. Unfortunately oglplus uses features that aren't implemented on VS 2013, resulting in a compile failure. </p> <p> While a more fine grained approach might solve this, it would be complicated (how exactly do you break down all the various C++11 features into bits that are supported and bits that arent? How do downstream developers actually use that information?). I think a more conservative approach is called for. If a feature isn't <em>fully</em> supported, then the corresponding NO_CXX11_FEATURE_NAME define should be turned on. </p> <p> You could add a 'BOOST_PARTIAL_CXX11_FEATURE_NAME' flag indicating partial support without delving into the issue of what parts are actually supported, so that downstream developers could potentially do something, knowing that by relying on a PARTIAL declaration, they were treading on thin ice. </p> <p> Failing to turn on the flag when the feature isn't fully supported leads to situations like mine, where I file a bug in a library I'm using, only to discover that the upstream dev is using Boost and C++, apparently correctly, but that because my compiler only has partial support for a feature, I can't build without jumping through hoops. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Veena</dc:creator> <pubDate>Wed, 01 Feb 2017 07:16:18 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/10215#comment:2 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10215#comment:2</guid> <description> <p> Hello, </p> <p> I'm using boost 1.59 whereas my code is compiling with VS2013. I see that this patch is not present in boost-1.59 which is causing some issues. Reapplying this patch back to 1.59, the issues get resolved. </p> <p> Attached is the diff. Hope this helps others who are facing similar issue </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Veena</dc:creator> <pubDate>Wed, 01 Feb 2017 07:17:13 GMT</pubDate> <title>attachment set https://svn.boost.org/trac10/ticket/10215 https://svn.boost.org/trac10/ticket/10215 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">visual.diff</span> </li> </ul> <p> Patch to boost 1.59 visualc.hpp </p> Ticket John Maddock Tue, 31 Jul 2018 18:36:48 GMT status changed; resolution set https://svn.boost.org/trac10/ticket/10215#comment:3 https://svn.boost.org/trac10/ticket/10215#comment:3 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> Not sure when, but this appears fixed now. </p> Ticket