--- Comment #6 from paolo dot carlini at oracle dot com 2009-12-11 21:04
---
Thanks. This specific issue I will fix in one day or so. But be warned that
until DR 1133 is resolved by the ISO C++ Committee likely you will encounter
problems with list::splice and list::merge.
--
http:
--- Comment #5 from rwgk at yahoo dot com 2009-12-11 19:27 ---
Thanks for the fast response!
Everything else we have works with -std=c++0x.
If this issue is fixed I could keep testing with -std=c++0x,
which I imagine could be of great value long term.
(We have several 100k of sources + b
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #4 from paolo dot carlini at oracle dot com 2009-12-11 18:43
---
Bah, we can use some std::move(s) in the splice and merge calls used by sort,
and solve this. We'll be reverted as unnecessary when DR 1133 will be resolved,
but maybe can make people more happy for the time be
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-11 18:22
---
:) Sorry, this issue has nothing to do with std::bind (ansd std::tr1::bind) of
course. This is actually about list::splcie and list::merge, which indeed are
still in flux in the WP, see DR 1133, or:
http://g
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-11 18:17
---
The std::, c++0x, version, is in flux. If you want the old behavior, just use
std::tr1::bind for now, and do not expect and C++0x-conforming behavior.
Really, no point in keeping open issues vs ongoing C++0x wo
--- Comment #1 from rwgk at yahoo dot com 2009-12-11 18:05 ---
Created an attachment (id=19277)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19277&action=view)
reproducer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42352
