[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument
--- Comment #1 from paolo dot carlini at oracle dot com 2008-10-13 08:44 --- Apparently the other library doesn't implement the resolution of DR 109 (if I comment out the additional operator() the code compiles). In any case, there are very long standing issues with those facilities, which will be deprecated in C++0x (we already moved the code to include/backward/) and replaced by bind. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument
--- Comment #2 from igodard at pacbell dot net 2008-10-13 15:18 --- Deprecated or not, shouldn't it work up until when it is actually removed? And forgive me, but I don't understand the relevance of DR 109 here. Perhaps you meant some other number? Lastly, if this is not a compiler issue should I file it against c++lib instead? Ivan -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument
--- Comment #3 from paolo dot carlini at oracle dot com 2008-10-13 15:27 --- (In reply to comment #2) Deprecated or not, shouldn't it work up until when it is actually removed? It works perfectly well, as designed, without regressions, it's just that implementing the resolution of library DR 109: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#109 causes this rejection. As I said already, these issues are *known* by the Committee and that's why those facilities are considered unreparably flawed in general, thus deprecated, and replaced by bind in C++0x. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument
--- Comment #4 from igodard at pacbell dot net 2008-10-13 16:06 --- Ah - I was looking at language DR109, not library DR109. However, the correct DR says the committee approved the example reported here (and adds the fix) so gcc appears to be in error to fail it. However, there is the curious remark: Howard believes there is a flaw in this resolution. See c++std-lib-9127. We may need to reopen this issue. Unfortunately Google turns up nothing for c++std-lib-9127 except this cryptic message, and just 9127 and other variations aren't productive either. Can you tell me where to find it? -- igodard at pacbell dot net changed: What|Removed |Added CC||igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument
--- Comment #5 from paolo dot carlini at oracle dot com 2008-10-13 16:23 --- (In reply to comment #4) Ah - I was looking at language DR109, not library DR109. However, the correct DR says the committee approved the example reported here (and adds the fix) so gcc appears to be in error to fail it. That't *not* true. The example in DR 109 does *not* compile if the additional operator() are not added and does when the resolution of DR 109 is implemented. However, there is the curious remark: Howard believes there is a flaw in this resolution. See c++std-lib-9127. We may need to reopen this issue. In any case, this is moot. As I tried to explain, nobody really cares these days about those bind1st and bind2nd binders, in the CD1 C++0x are already in an appendix, as deprecated features, with the exact resolution of issue DR 109 included, as we are doing. Unfortunately Google turns up nothing for c++std-lib-9127 except this cryptic message, and just 9127 and other variations aren't productive either. Can you tell me where to find it? It's a message to the ISO library reflector. Really, given the above, I would suggest not wasting further time... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument
--- Comment #6 from igodard at pacbell dot net 2008-10-13 17:01 --- Then I'm hopelessly confused. It's clear that my report and the example in DR109 are the same problem. You say: The example in DR 109 does *not* compile if the additional operator() are not added and does when the resolution of DR 109 is implemented. That makes sense - with the addition of the overload my example will compile too. So it appears that gcc (at least 4.3.1) does *not* implement DR109. You then say, in essence, So what, it's deprecated in C++0X and there's a better solution therein, get over it. Would that I could! Unfortunately, out here in the real world some of us have legal, business, and practical mandates that *require* us to use only *officially issued* language standards, and explicitly prohibit us from using extensions, next-release features and so on. On pain of being fired, if not worse. I realize that keeping up with soon-to-be-obviated DRs is not the most professionally satisfying activity. But the fix here seems so well known and trivial that I don't understand a reluctance to put it in. However, gcc is a volunteer project and if nobody will put it in then nobody will put it in. May I suggest that the proper resolution of my report is VERIFIED - WONT FIX? Or perhaps I've again misunderstood? -- igodard at pacbell dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument
--- Comment #7 from paolo dot carlini at oracle dot com 2008-10-13 17:13 --- (In reply to comment #6) Then I'm hopelessly confused. It's clear that my report and the example in DR109 are the same problem. You say: The example in DR 109 does *not* compile if the additional operator() are not added and does when the resolution of DR 109 is implemented. That makes sense - with the addition of the overload my example will compile too. So it appears that gcc (at least 4.3.1) does *not* implement DR109. No It does *exactly* implement the DR, it SIMPLY adds the two operator(). Your problem is totally different, has to do with the obnoxious reference to reference issue, which plagued C++03. The overloads are already there, check again in the code of the library, but are there to fix a completely different issue, that reported in DR 109, which has to do with non-const members. Please, do not re-open PR at your will. This issue is absolutely clear to the maintainers of the library and nobody (I repeat nobody) will take any further real action, irrespective of you reopening it or not. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument
--- Comment #8 from igodard at pacbell dot net 2008-10-13 17:55 --- OK, thanks for your time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
[Bug libstdc++/37811] bind1st fails on mem_fun with reference argument
--- Comment #9 from paolo dot carlini at oracle dot com 2008-10-13 19:07 --- FYI, I had a quick look to the library likely used by current Comeau: it doesn't implement the letter of the Standard for bind1st co, neither before nor after DR 109. It tries to circumvent the limitations of the original design. To be clear again, we'll not follow that route, we deliver a strictly conforming implementation, DR 109 included and included the fact that the facility is considered deprecated, essentially frozen and ready for removal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37811
