Boost C++ Libraries: Ticket #13423: boost log misses user-defined operator<< in MSVC 2017 1.12.111.1002 https://svn.boost.org/trac10/ticket/13423 <p> Defining an <code>operator&lt;&lt;</code> on <code>std::ostream</code> for an enum that is used as the severity attribute in the <code>severity_logger_mt</code> source usually means that printing the severity attribute of a record in a custom formatter uses that override. </p> <p> With some particular optimisation options in MSVC (see below), and a setup where the function using the logging is not in the same translation unit but takes an argument of the severity enum type this behaviour goes away and instead the logging prints out the integer cast of that enum. </p> <pre class="wiki"># Table of when the problem occurs under MSVC. # the "get INFO?" column is "NO" when the problem occurs # | Optimise References | Inline Function Expansion | Whole Program Optimisation | get INFO? | # |---------------------+---------------------------+----------------------------+-----------| # | false | disabled | false | NO | # | true | disabled | false | NO | # | false | only explicit inline | false | YES | # | true | only explicit inline | false | YES | # | false | disabled | true | ERROR | # | true | disabled | true | NO | # | false | only explicit inline | true | ERROR | # | true | only explicit inline | true | NO | </pre><p> I haven't been able to reproduce this behaviour on Linux under either clang or gcc. </p> <p> A zip file of the smallest problematic example I've managed to find is attached. In the example, most of the code is in a file called <code>logger.cpp</code>. There are two functions in <code>example_project.cpp</code>, on is there for the executable to see, while the other that is simply there to </p> <p> On linux unzip, then make and run for both <code>gcc</code> and <code>clang</code> with <code>make all</code>. You can see that the severity is printed out as <code>INFO</code>. </p> <p> On Windows open the <code>temp_solution.sln</code> file with MSVC, click <code>Build all</code>, then run the resulting <code>example_project.exe</code> binary. You can see that the severity (and some other printouts of the enum) are printed out as <code>1</code>. If I define an override on the <code>basic_record_ostream</code> template, then placing an enum instance onto the logging stream picks up the override, while the severity argument doesn't. </p> <p> You can allow <code>Inline function expansion</code> under project properties -&gt; C/C++ -&gt; Optimization , this then picks up the user-defined override. </p> <p> In <code>example_project.cpp</code> there is a function <code>LogLevelFun()</code> that takes a <code>LogLevelEnum</code> as an argument. I do nothing with this function, but if it takes an integer as argument instead of the enum then the problem goes away. </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/13423 Trac 1.4.3 matthew.malcomson@… Sun, 28 Jan 2018 10:25:53 GMT attachment set https://svn.boost.org/trac10/ticket/13423 https://svn.boost.org/trac10/ticket/13423 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">example.zip</span> </li> </ul> <p> minimal example </p> Ticket Andrey Semashev Sun, 28 Jan 2018 13:50:28 GMT status changed; resolution set https://svn.boost.org/trac10/ticket/13423#comment:1 https://svn.boost.org/trac10/ticket/13423#comment:1 <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">wontfix</span> </li> </ul> <p> I have been able to reproduce this with Visual Studio 2017 v15.5.5, compiler version 19.12.25835. The program fails to use the custom <code>operator&lt;&lt;</code> when compiled with this command line: </p> <blockquote> <p> cl /Od /MD /EHsc /I &lt;Boost root&gt; -c &lt;source file&gt; </p> </blockquote> <p> and succeeds when /Ob1 is added. </p> <p> Unfortunately, this is a compiler bug that I cannot work around in the library. Turning optimizations on or off definitely should not influence function lookup rules. I recommend you report this to <a class="ext-link" href="https://connect.microsoft.com/"><span class="icon">​</span>Microsoft</a>. </p> Ticket