Modify

Ticket #7663 (closed Bugs: fixed)

Opened 17 months ago

Last modified 11 months ago

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

Reported by: jeffrey.flinn@… Owned by: eric_niebler
Milestone: To Be Determined Component: result_of
Version: Boost 1.52.0 Severity: Problem
Keywords: Cc:

Description

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

Attachments

chunduru ssc.xps Download (171.9 KB) - added by kkr 2 months ago.
msword

Change History

comment:1 Changed 15 months ago by anonymous

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

comment:2 Changed 14 months ago by anonymous

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

comment:3 Changed 14 months ago by eric_niebler

  • Owner changed from no-maintainer to eric_niebler
  • Component changed from utility to result_of
  • Severity changed from Cosmetic to Problem

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

comment:4 Changed 14 months ago by 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)
        [...]

comment:5 follow-up: ↓ 6 Changed 14 months ago by eric_niebler

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

comment:6 in reply to: ↑ 5 Changed 14 months ago by 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!

comment:7 Changed 14 months ago by 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.

comment:8 Changed 14 months ago by 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.

comment:9 Changed 14 months ago by 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.

comment:10 Changed 14 months ago by 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?

comment:11 follow-up: ↓ 12 Changed 13 months ago by eric_niebler

  • Status changed from new to closed
  • Resolution set to fixed

Fixed in [83381].

comment:12 in reply to: ↑ 11 Changed 13 months ago by viboes

Replying to eric_niebler:

Fixed in [83381].

This change set doesn't exists yet !

comment:13 Changed 13 months ago by 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

comment:14 Changed 12 months ago by 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?

comment:15 Changed 11 months ago by 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)

Changed 2 months ago by kkr

msword

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.