Boost C++ Libraries: Ticket #7663: warning C4913: user defined binary operator ',' exists but no overload could convert all operands, default built-in binary operator ',' used

anonymous — Thu, 31 Jan 2013 07:16:40 GMT

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

anonymous — Wed, 06 Feb 2013 08:15:33 GMT

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

owner, component, severity changed

Eric Niebler — Thu, 07 Feb 2013 04:23:48 GMT

owner changed from No-Maintainer to Eric Niebler
component utility → result_of
severity Cosmetic → Problem

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

Zenju — Fri, 08 Feb 2013 23:24:16 GMT

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 — Sun, 17 Feb 2013 23:56:12 GMT

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

pbf@… — Fri, 22 Feb 2013 02:12:38 GMT

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 — Fri, 22 Feb 2013 02:15:07 GMT

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 — Fri, 22 Feb 2013 03:53:39 GMT

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.

Fri, 22 Feb 2013 05:04:42 GMT

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@… — Wed, 06 Mar 2013 18:13:34 GMT

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?

status changed; resolution set

Eric Niebler — Sun, 10 Mar 2013 00:10:42 GMT

status new → closed
resolution → fixed

Fixed in [83381].

viboes — Sun, 10 Mar 2013 07:53:48 GMT

Replying to eric_niebler:

Fixed in [83381].

This change set doesn't exists yet !

Eric Niebler — Sun, 10 Mar 2013 21:08:04 GMT

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

Thu, 25 Apr 2013 16:05:43 GMT

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@… — Sun, 12 May 2013 13:22:20 GMT

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)

attachment set

kkr — Thu, 06 Feb 2014 12:23:08 GMT

attachment → chunduru ssc.xps

msword