gcc-3.4 is now frozen. I wonder if anyone is testing boost compat? I have tried compiling some of my code using gcc version 3.4.0 20040327 (Red Hat Linux 3.4.0-0.9). There are usually a LOT of errors. gcc-3.4 doesn't seem to like boost iterator adaptor stuff, in particular. Also lambda. Many errors are of this nature: src/c_to_r.hpp:83: error: there are no arguments to `base_reference' that depend on a template parameter, so a declaration of `base_reference' must be available
Neal D. Becker wrote:
gcc-3.4 doesn't seem to like boost iterator adaptor stuff, in particular. Also lambda.
Weird, I think I could compile most of those libraries without big problems. Any single test which reliably fails with 3.4.0?
Many errors are of this nature: src/c_to_r.hpp:83: error: there are no arguments to `base_reference' that depend on a template parameter, so a declaration of `base_reference' must be available
GCC 3.4.0 implements two-stage name lookup, which is not found in previous versions of GCC or MSVC 71 (that happens to be de-fact standard for Boost development). One of the net results is that names in dependent bases are not inspected during unqualified name lookup in templates. I suggest you review http://gcc.gnu.org/gcc-3.4/changes.html for more infos. In my experience, libraries which were previously compiled with an EDG compiler (Comeau / Intel) have almost no problems, while libraries developed only with MSVC, CW, or GCC need to be fixed. I'm more than willing to help fixing Boost wrt GCC 3.4.0, and analyzing bugs in GCC itself which might be discovered in the process. Feel free to contact me on this regard. -- Giovanni Bajo
"Giovanni Bajo" <giovannibajo@libero.it> writes:
Neal D. Becker wrote:
gcc-3.4 doesn't seem to like boost iterator adaptor stuff, in particular. Also lambda.
Weird, I think I could compile most of those libraries without big problems. Any single test which reliably fails with 3.4.0?
Many errors are of this nature: src/c_to_r.hpp:83: error: there are no arguments to `base_reference' that depend on a template parameter, so a declaration of `base_reference' must be available
GCC 3.4.0 implements two-stage name lookup, which is not found in previous versions of GCC or MSVC 71 (that happens to be de-fact standard for Boost development). One of the net results is that names in dependent bases are not inspected during unqualified name lookup in templates. I suggest you review http://gcc.gnu.org/gcc-3.4/changes.html for more infos. In my experience, libraries which were previously compiled with an EDG compiler (Comeau / Intel) have almost no problems, while libraries developed only with MSVC, CW, or GCC need to be fixed.
We still do test all of Boost with many compilers implementing 2-phase lookup, including metrowerks, intel, and comeau. I'm surprised that you report it's turning up any Boost bugs, especially in iterator adaptors. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
In my experience, libraries which were previously compiled with an EDG compiler (Comeau / Intel) have almost no problems, while libraries developed only with MSVC, CW, or GCC need to be fixed.
We still do test all of Boost with many compilers implementing 2-phase lookup, including metrowerks, intel, and comeau. I'm surprised that you report it's turning up any Boost bugs, especially in iterator adaptors.
Sorry if I was vague, but my sentence above wasn't specifically about Boost libraries. Boost libraries are obviously OK (or mostly OK at least) because of the wide testing, as you say. -- Giovanni Bajo
David Abrahams wrote:
"Giovanni Bajo" <giovannibajo@libero.it> writes:
Neal D. Becker wrote:
gcc-3.4 doesn't seem to like boost iterator adaptor stuff, in particular. Also lambda.
Weird, I think I could compile most of those libraries without big problems. Any single test which reliably fails with 3.4.0?
Many errors are of this nature: src/c_to_r.hpp:83: error: there are no arguments to `base_reference' that depend on a template parameter, so a declaration of `base_reference' must be available
GCC 3.4.0 implements two-stage name lookup, which is not found in previous versions of GCC or MSVC 71 (that happens to be de-fact standard for Boost development). One of the net results is that names in dependent bases are not inspected during unqualified name lookup in templates. I suggest you review http://gcc.gnu.org/gcc-3.4/changes.html for more infos. In my experience, libraries which were previously compiled with an EDG compiler (Comeau / Intel) have almost no problems, while libraries developed only with MSVC, CW, or GCC need to be fixed.
We still do test all of Boost with many compilers implementing 2-phase lookup, including metrowerks, intel, and comeau. I'm surprised that you report it's turning up any Boost bugs, especially in iterator adaptors.
It looks like the iterator adaptors problem was my fault. Sorry for false alarm. Lambda does need to be fixed. I guess it is in cvs now. Are there plans to for a bug fix release (1.31.1)?
Any idea what to do about these? /usr/local/src/boost_1_31_0/boost/lambda/detail/operator_return_type_traits.hpp:887: error: use of `map' is ambiguous /usr/local/src/boost_1_31_0/boost/lambda/detail/operator_return_type_traits.hpp:865: error: first declared as `template<class Key, class T, class Cmp, class Allocator> struct std::map' here /usr/lib/gcc/i386-redhat-linux/3.4.0/../../../../include/c++/3.4.0/bits/stl_map.h:92: error: also declared as `template<class _Key, class _Tp, class _Compare, class _Alloc> class __gnu_norm::map' here
On Apr 20, 2004, at 12:29 PM, Neal D. Becker wrote:
Any idea what to do about these?
Should be gone now. Jaakko
/usr/local/src/boost_1_31_0/boost/lambda/detail/ operator_return_type_traits.hpp:887: error: use of `map' is ambiguous /usr/local/src/boost_1_31_0/boost/lambda/detail/ operator_return_type_traits.hpp:865: error: first declared as `template<class Key, class T, class Cmp, class Allocator> struct std::map' here /usr/lib/gcc/i386-redhat-linux/3.4.0/../../../../include/c++/3.4.0/ bits/stl_map.h:92: error: also declared as `template<class _Key, class _Tp, class _Compare, class _Alloc> class __gnu_norm::map' here
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Neal D. Becker wrote:
/usr/local/src/boost_1_31_0/boost/lambda/detail/operator_return_type_traits.hpp :887:
error: use of `map' is ambiguous
/usr/local/src/boost_1_31_0/boost/lambda/detail/operator_return_type_traits.hpp :865:
error: first declared as `template<class Key, class T, class Cmp, class Allocator> struct std::map' here
/usr/lib/gcc/i386-redhat-linux/3.4.0/../../../../include/c++/3.4.0/bits/stl_map .h:92:
error: also declared as `template<class _Key, class _Tp, class _Compare, class _Alloc> class __gnu_norm::map' here
Declaring std::map outside the system headers yields undefined behaviour, lambda shouldn't be doing that. I understand it works almost everywhere, though. Good news is that it should work again in GCC 3.4.0 final. But that doesn't make it right. -- Giovanni Bajo
participants (5)
-
David Abrahams -
Giovanni Bajo -
Jaakko Jarvi -
Neal Becker -
Neal D. Becker