Boost C++ Libraries: Ticket #8463: function_output_iterator: MSVC warning C4512 https://svn.boost.org/trac10/ticket/8463 <p> In <code>boost/function_output_iterator</code> the struct <code>function_output_iterator::output_proxy</code> yields this warning: "assignment operator could not be generated." I see this primarily using signals2, where the iterator class is created using <code>boost::signals2::detail::does_nothing</code> as the iterator template argument. </p> <p> The warning is due to the proxy's const data member, and probably not dependent on the iterator template argument. </p> <p> The struct also has a templated operator= defined, but not of the sort that would work as a copy-assignment. </p> <p> Other libraries (fusion, spirit, statechart in particular) have implemented do-nothing assignment operators (or just declarations) to overcome similar symptoms. If I do the same for this class in my local copy -- simply add a declaration for this particular signature: </p> <pre class="wiki"> private: output_proxy&amp; operator=(output_proxy const &amp;src); </pre><p> the warning goes away; however, I can't be sure this doesn't break something. It seems unlikely, as I can run code with the warning and my signals seem to work just fine. </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/8463 Trac 1.4.3 viboes Sat, 20 Apr 2013 10:55:12 GMT component changed; owner set https://svn.boost.org/trac10/ticket/8463#comment:1 https://svn.boost.org/trac10/ticket/8463#comment:1 <ul> <li><strong>owner</strong> set to <span class="trac-author">jeffrey.hellrung</span> </li> <li><strong>component</strong> <span class="trac-field-old">None</span> → <span class="trac-field-new">iterator</span> </li> </ul> Ticket Paul Saville <boost_8463@…> Fri, 24 May 2013 00:19:40 GMT <link>https://svn.boost.org/trac10/ticket/8463#comment:2 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/8463#comment:2</guid> <description> <p> MSVC emits warning C4512 because output_proxy contains a reference member variable, which makes default member-wise assignment impossible. I don't yet understand why the compiler refuses to use the operator= template member function to generate an acceptable (although apparently flawed) assignment operator. Changing the <a class="missing wiki">UnaryFunction</a> reference to an ordinary member variable made the warning go away for me. This changes the behaviour so it's not a fix, just an experiment. I also added an assert() to determine whether the operator= template is ever actually called at runtime. </p> <pre class="wiki"> struct output_proxy { output_proxy( UnaryFunction&amp; f ) : m_f( f ) {} template&lt; class T &gt; output_proxy&amp; operator=( const T&amp; value ) { m_f( value ); assert( false ); return *this; } // UnaryFunction&amp; m_f; UnaryFunction m_f; }; </pre><p> I'm also somewhat concerned about function_output_iterator::operator*(). It returns an output_proxy instance containing a reference to private member function_output_iterator::m_f, which is a strange thing to do. If there is an esoteric idiom in play here, can anyone point out what it is? </p> </description> <category>Ticket</category> </item> <item> <author>guy@…</author> <pubDate>Tue, 02 Jul 2013 12:29:49 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/8463#comment:3 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/8463#comment:3</guid> <description> <p> This appears to be a duplicate of <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/3857" title="#3857: Bugs: c4512 warning using signals2 with boost 1.41 on VS2005 (closed: invalid)">#3857</a>. However, that ticket has been closed with the advice to silence the warning or submit a patch. Does the problem solution above constitute a patch? </p> </description> <category>Ticket</category> </item> <item> <author>Mike Cowperthwaite <michael.cowperthwaite@…></author> <pubDate>Tue, 02 Jul 2013 18:08:07 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/8463#comment:4 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/8463#comment:4</guid> <description> <p> 1) fmhess's 'advice' at that other bug looks like knee-jerk Microsoft-blaming, altho he might technically be right that these warnings are spurious. (a) As noted in the original report here, several Boost libraries have already taken steps to prevent them. (b) A spurious warning here might be a non-spurious warning elsewhere; and this warning cannot be suppressed using MS's <code>#pragma warning</code>. </p> <p> 2) Not sure which "problem solution above" you're referring to: there is code in comment 2, and code in the original report. The code in the original report is similar to the solutions I found in other Boost libraries. The code in comment 2 looks like it might work fine; whether copying a <code>UnaryFunction</code> object with every instance of <code>output_proxy</code> would be undesirable overhead, I cannot say. </p> <p> I'm curious to know if Paul Saville's <code>assert()</code> has ever been triggered. (Also, Paul correctly pinned the cause on the "reference member variable," not a "const data member" as I originally stated.) </p> </description> <category>Ticket</category> </item> <item> <author>Guy Bolton King <guy@…></author> <pubDate>Wed, 03 Jul 2013 10:54:35 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/8463#comment:5 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/8463#comment:5</guid> <description> <p> Replying to <a class="ticket" href="https://svn.boost.org/trac10/ticket/8463#comment:4" title="Comment 4">Mike Cowperthwaite &lt;michael.cowperthwaite@…&gt;</a>: </p> <blockquote class="citation"> <p> 2) Not sure which "problem solution above" you're referring to: there is code in comment 2, and code in the original report. </p> </blockquote> <p> Sorry, the code in the original report. </p> <blockquote class="citation"> <p> I'm curious to know if Paul Saville's <code>assert()</code> has ever been triggered. (Also, Paul correctly pinned the cause on the "reference member variable," not a "const data member" as I originally stated.) </p> </blockquote> <p> I would imagine it is never triggered: if you only get a C4512 warning, but no errors about the assignment operator not existing, then surely it's not being called by anything. </p> <p> Is there anyone from Boost looking at this who can say whether the proposed code in the original report is acceptable as a patch, or whether more is required to fix this? Incidentally fmhess appears to one of the authors of signals2 (according to the docs anyway), so I'm hoping he's changed his mind about this since the response to <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/3857" title="#3857: Bugs: c4512 warning using signals2 with boost 1.41 on VS2005 (closed: invalid)">#3857</a>. </p> </description> <category>Ticket</category> </item> </channel> </rss>