Boost C++ Libraries: Ticket #8463: function_output_iterator: MSVC warning C4512

component changed; owner set

viboes — Sat, 20 Apr 2013 10:55:12 GMT

owner set to jeffrey.hellrung
component None → iterator

Fri, 24 May 2013 00:19:40 GMT

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 UnaryFunction 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.

  struct output_proxy
  {
    output_proxy( UnaryFunction& f ) : m_f( f ) {}
    template< class T > output_proxy& operator=( const T& value )
    {
      m_f( value );
      assert( false );
      return *this;
    }
//    UnaryFunction& m_f;
    UnaryFunction m_f;
  };

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?

guy@… — Tue, 02 Jul 2013 12:29:49 GMT

This appears to be a duplicate of #3857. 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?

Tue, 02 Jul 2013 18:08:07 GMT

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 #pragma warning.

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 UnaryFunction object with every instance of output_proxy would be undesirable overhead, I cannot say.

I'm curious to know if Paul Saville's assert() has ever been triggered. (Also, Paul correctly pinned the cause on the "reference member variable," not a "const data member" as I originally stated.)

Wed, 03 Jul 2013 10:54:35 GMT

Replying to Mike Cowperthwaite <michael.cowperthwaite@…>:

2) Not sure which "problem solution above" you're referring to: there is code in comment 2, and code in the original report.

Sorry, the code in the original report.

I'm curious to know if Paul Saville's assert() has ever been triggered. (Also, Paul correctly pinned the cause on the "reference member variable," not a "const data member" as I originally stated.)

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.

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 #3857.