warning C4913: user defined binary operator ',' exists but no overload could convert all operands, default built-in binary operator ',' used

[jeffrey.flinn@…]

Gennadiy reports in trunk:

boost/thread/future.hpp(378) : warning C4913: user defined binary operator ',' exists but no overload could convert all operands, default built-in binary operator ',' used

I get with VC2012 and boost_1_52_0:

boost_1_52_0\boost/thread/future.hpp(293): warning C4913: user defined binary operator ',' exists but no overload could convert all operands, default built-in binary operator ',' used

Nigel Pattinson reports a similar issue with VC2008 and unspecified boost version. He finds that:

"The comma operator in question is the one in boost/utility/result_of.hpp at line 74 - if I comment that line out everything compiles fine. It is just a warning, so rather than changing result_of.hpp our current workaround is just to disable the warning around the inclusion of future.hpp ."

[anonymous]

The problem also appear with MSVC 10.0, I don't know how to fix it.

[anonymous]

The problem also appears with MSVC 11.0 (aka Visual Studio 2012)

[Eric Niebler]

The warning should probably be suppressed in boost/utility/result_of.hpp. I'll investigate.

[Zenju]

I have the same problem, but disabling the warning when including "thread.hpp" is not sufficient. ADL drags in this overload (and thereby the warning) on multiple occasions in my own code when using a member of namespace boost with the commma-operator, e.g. a boost::unique_future:

    std::list<boost::unique_future<bool>> dirEx;
    [...]

    auto itDirname = dirnames.begin();
    for (auto it = dirEx.begin(); it != dirEx.end(); ++it, ++itDirname)
        [...]

[Eric Niebler]

(In [82960]) disable annoying msvc warning, refs #7663

[pbf@…]

For the record, changelist 82960 does not appear sufficient to fix the problem. In certain circumstances, I still get:

future.hpp(354): warning C4913: user defined binary operator ',' exists but no overload could convert all operands, default built-in binary operator ',' used

I've gone so far as to search for all headers that define an operator, overload, and place similar warning disables, however the pesky warning still exists. It's a persistent sucker!

[Eric Niebler]

I'm afraid there's nothing more I can do besides disabling the warning. If this really doesn't silence the warning for you, then it's a bug in the msvc compiler. You should report it to them.

[Steven Watanabe]

I would assume that the warning is issued at the point of overload resolution, not the point where operator, is defined. Thus, disabling the warning in headers that define an operator, wouldn't seem to be enough.

[Peter Fry <pbf@…>]

In the end I've had to work around this by placing the warning disable in boost/config/compiler/visualc.hpp, and therefore ensure it gets disabled wherever I'm using boost (the price you pay for building your code with warn as error and warning level 4). Of course this is fragile since presumably if the first time boost/config.hpp is included, it's placed within a warning disable push/pop block, it may not suppress the warning at the point of overload resolution (thanks to the include guard). I wouldn't therefore propose this as a patch, but hopefully it'll fit my needs.

[gast128@…]

We use level 4 and we also have to surpress Boost warnings. For this issue I made 2 other tickets: #7702, #7188 which may be closed then?

[Eric Niebler]

Fixed in [83381].

[viboes]

Replying to eric_niebler:

Fixed in [83381].

This change set doesn't exists yet !

[Eric Niebler]

Sure it does.

C:\boost\org\branches\release>svn diff -c 83381 boost\utility\result_of.hpp
Index: boost/utility/result_of.hpp
===================================================================
--- boost/utility/result_of.hpp (revision 83380)
+++ boost/utility/result_of.hpp (revision 83381)
@@ -68,6 +68,13 @@

 #ifdef BOOST_NO_SFINAE_EXPR

+// There doesn't seem to be any other way to turn this off such that the presence of
+// the user-defined operator,() below doesn't cause spurious warning all over the place,
+// so unconditionally turn it off.
+#if BOOST_MSVC
+#  pragma warning(disable: 4913) // user defined binary operator ',' exists but no overload could convert all operands, default built-in binary operator ',' used
+#endif
+
 struct result_of_private_type {};

 struct result_of_weird_type {

Property changes on: boost/utility/result_of.hpp
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /trunk/boost/utility/result_of.hpp:r82960

[Peter Brockamp <p.brockamp@…>]

This problem still persists in boost V1.53 and it does occur equally to other versions in VS 2005, too! I cannot see the changes mentioned above concerning changeset [83381] in the source code of the current boost V1.53!?! How come if this was already fixed in V1.52?

And I have another remark:

Basically it's not this library's fault that this warning is being raised, but on the other hand this warning has its reason! Consider:

Overloading the comma-operator could unexpectedly and subliminally alter the functionality of a library or even worse the code of the library's user. The overloaded operator naturally just needs to fit the datatypes given to a call where overload resolution takes place! Therefor every implementor should think twice when overloading operators.

Now, there are several places in boost where overloading the comma-operator is being done. These might have their reasons and it is something which is not necessarily being done here but could equally well have been pulled in from another boost library, dunno. However, the warning shows that the compiler saw the operator and considered it for overload-resolution, when compiling some user code - which I regard as being a bad thing! This operator should in my opinion not be automatically visible to user code, as it's just a detail of boost's implementation. Thus, the comma-operator should have been put in a private namespace of the overloading library (not being pulled in by a using ... ), so that it is not beeing considered by Koenig-lockup when compiling user code!

Here, the emitted warning shows you that luckily(!) things did not get wrong! It says "Hey, I considered the comma-operator for overload-resolution, but the parameter types did not fit, so I used the standard operator." - which is probably what the user intended! So, I think it would be a good thing if boost libraries would encapsulate overloads like this, allowing this warning to be left switched on.

To come to an end: Disabling this warning is not an optimal solution here (though at the moment unavoidable), things should better be altered accordingly so the warning is not being risen. Maybe with boost's next version?

[kovarex@…]

This warning happened to me when I used boost::circular_buffer<float> (with primitive type),

When I did struct Item {

float value;

};

boost::circular_buffer<Item> instead, it worked fine. (Boost 1.53)

[kkr]

msword