Richard Webb wrote:

The MPL failure is a problem in the for_each test itself. Theres a call to ... bind(&std::vector<int>::push_back... which seems to be failing because it doesn't know which push_back to call (the one that takes 'const int&' or the one that takes 'int&&').

The same failure occurs in VC10.

The assign::list_inserter test has the same problem. I opened a ticket about this failure on VC10 @ https://svn.boost.org/trac/boost/ticket/3073. In addition, there are some failures in the assign/std test due to a 'typedef pair<string,int> tuple;', which is clashing with std::tuple. -- View this message in context: http://www.nabble.com/Failures-for-GCC-4.4.1-with-gnu%2B%2B0x-tp25278446p252... Sent from the Boost - Dev mailing list archive at Nabble.com.

John Maddock wrote:

The config failures are down to boost_no_deleted_functions.ipp which is one of yours - maybe this isn't supported in GCC yet?

I notice that boost_no_deleted_functions.ipp contains namespace boost_no_constexpr { I guess that should be namespace boost_no_deleted_functions { ? -- View this message in context: http://www.nabble.com/Failures-for-GCC-4.4.1-with-gnu%2B%2B0x-tp25278446p253... Sent from the Boost - Dev mailing list archive at Nabble.com.

Eric Niebler-3 wrote:

I see only the beginning of an error or warning backtrace, followed by "[The content has been trimmed by the report system because it exceeds 65536 bytes]". Where can I find the full error message?

I've attached an error log from the test_actions test on Mingw 4.4.0. The test_symbols test fails in the same way on 4.4.0, though it passes on 4.4.1. http://www.nabble.com/file/p25291231/test_actions.zip test_actions.zip -- View this message in context: http://www.nabble.com/Failures-for-GCC-4.4.1-with-gnu%2B%2B0x-tp25278446p252... Sent from the Boost - Dev mailing list archive at Nabble.com.

I think gcc behaves correctly. The non-0x pair has a two-argument constructor taking const references to T1 and T2 (20.2.2p2). Therefore the 0 you pass is directly regarded be the null pointer constant. The 0x pair has a 1...N argument _template_ constructor (20.2.2p6 of the current draft). The 0 is regarded to be an int, and therefore you are passing an actual int to initialize a pointer. std::pair<int, int*> x(0,nullptr); or std::pair<int, int*> x(0,static_cast<void*>(0)); should work fine though. -Christopher Beman Dawes schrieb:

On Thu, Sep 3, 2009 at 11:27 AM, Beman Dawes<bdawes@acm.org> wrote:

...

Thanks to Noel Belcourt, the trunk Sandia-gcc tests show results side-by-side for gcc 4.4.1 without and with C++0x features enabled.

See http://beta.boost.org/development/tests/trunk/developer/summary.html

Several Boost libraries are passing without 4.4.1 C++0x features but failing with them:

http://beta.boost.org/development/tests/trunk/developer/assign.html ...

I missed iostreams. The problem seems to be a bug in gcc. This program:

#include <utility>

int main() { std::pair<int, int*> x(0,0); return 0; }

compiles without -std=gnu++0x, but with -std=gnu++0x gets an error:

c:\gcc\bin\../lib/gcc/i386-pc-mingw32/4.4.0/../../../../include/c++/4.4.0/bits/stl_pair.h: In constr uctor 'std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = int, _U2 = int, _T1 = int, _T2 = int*]': cvt-0-to-ptr.cpp:5: instantiated from here c:\gcc\bin\../lib/gcc/i386-pc-mingw32/4.4.0/../../../../include/c++/4.4.0/bits/stl_pair.h:90: error: invalid conversion from 'int' to 'int*'

I tried to find this in gcc bugzilla, but didn't come up with anything. Is anyone else have any knowledge of this problem?

--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Sat, Sep 5, 2009 at 12:47 PM, Beman Dawes<bdawes@acm.org> wrote:

What about a macro "#define nullptr 0" that is only defined if the compiler does not support C++0x nullptr? It usually is a really bad idea to give a macro a lowercase name, but isn't this a really special case because nullptr is a C++0x keyword?

Never mind. It would break existing code. Google code search shows people already using the name, presumably in workarounds in preparation for 0x. --Beman

On Sat, Sep 5, 2009 at 10:25 AM, Steven Watanabe<watanabesj@gmail.com> wrote:

AMDG

Beman Dawes wrote:

...

On Thu, Sep 3, 2009 at 11:27 AM, Beman Dawes<bdawes@acm.org> wrote:

...

Thanks to Noel Belcourt, the trunk Sandia-gcc tests show results side-by-side for gcc 4.4.1 without and with C++0x features enabled.

See http://beta.boost.org/development/tests/trunk/developer/summary.html

Several Boost libraries are passing without 4.4.1 C++0x features but failing with them:

http://beta.boost.org/development/tests/trunk/developer/assign.html ...

I missed iostreams. The problem seems to be a bug in gcc. This program:

#include <utility>

int main() {  std::pair<int, int*> x(0,0);  return 0; }

compiles without -std=gnu++0x, but with -std=gnu++0x gets an error:

c:\gcc\bin\../lib/gcc/i386-pc-mingw32/4.4.0/../../../../include/c++/4.4.0/bits/stl_pair.h: In constr uctor 'std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = int, _U2 = int, _T1 = int, _T2 = int*]': cvt-0-to-ptr.cpp:5:   instantiated from here

c:\gcc\bin\../lib/gcc/i386-pc-mingw32/4.4.0/../../../../include/c++/4.4.0/bits/stl_pair.h:90: error:  invalid conversion from 'int' to 'int*'

I tried to find this in gcc bugzilla, but didn't come up with anything. Is anyone else have any knowledge of this problem?

This is a result of the addition of a templated constructor for std::pair in C++0x.  gcc seems to be behaving correctly.

Grrr... I'd forgotten about that. Thanks, --Beman

Bo Persson wrote:

Steven Watanabe wrote:

...

AMDG

Beman Dawes wrote: ...

...

I missed iostreams. The problem seems to be a bug in gcc. This program: #include <utility>

int main() { std::pair<int, int*> x(0,0); return 0; }

compiles without -std=gnu++0x, but with -std=gnu++0x gets an error:

c:\gcc\bin\../lib/gcc/i386-pc-mingw32/4.4.0/../../../../include/c++/4.4.0/bits/stl_pair.h: In constr uctor 'std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = int, _U2 = int, _T1 = int, _T2 = int*]': cvt-0-to-ptr.cpp:5: instantiated from here c:\gcc\bin\../lib/gcc/i386-pc-mingw32/4.4.0/../../../../include/c++/4.4.0/bits/stl_pair.h:90: error: invalid conversion from 'int' to 'int*'

I tried to find this in gcc bugzilla, but didn't come up with anything. Is anyone else have any knowledge of this problem?

This is a result of the addition of a templated constructor for std::pair in C++0x. gcc seems to be behaving correctly.

Yes, but that constructor is (was!) supposed to be constrained by a Constructible concept. The compiler correctly points out that the parameter fails that concept.

Interesting! .-)

This issue http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2940.html#811 is one of those solved by concepts that are now back.

Christopher Jefferson wrote:

On 5 Sep 2009, at 13:25, Beman Dawes wrote:

...

I missed iostreams. The problem seems to be a bug in gcc. This program:

#include <utility>

int main() { std::pair<int, int*> x(0,0); return 0; }

compiles without -std=gnu++0x, but with -std=gnu++0x gets an error:

c:\gcc\bin\../lib/gcc/i386-pc-mingw32/4.4.0/../../../../include/c++/4.4.0/bits/stl_pair.h:

In constr uctor 'std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = int, _U2 = int, _T1 = int, _T2 = int*]': cvt-0-to-ptr.cpp:5: instantiated from here c:\gcc\bin\../lib/gcc/i386-pc-mingw32/4.4.0/../../../../include/c++/4.4.0/bits/stl_pair.h:90:

error: invalid conversion from 'int' to 'int*'

This is technically a bug in the C++0x draft standard, but one which I hope will be fixed somehow before it is finalised, as it will break existing valid code, like this.

I agree. This is terrible. Has anyone filed an issue with the C++ committee about this? Beman? If not, I will. We now have field experience -- this is breaking real code. -- Eric Niebler BoostPro Computing http://www.boostpro.com