From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-06-02 20:14:13
At 10:01 AM 6/2/2003, David Abrahams wrote:
>I just checked in changes to the intel-win32-tools.jam file which
>enable argument-dependent lookup for all versions, since we were were
>incorrectly operating as though it was enabled for v7.1 anyway. I
>think we are still out-of-synch with the config, though. The config
>for the intel compiler contains:
># if defined(_MSC_VER) && (_MSC_VER <= 1300) // added check for <= VC 7
> // Intel C++ 5.0.1 uses EDG 2.45, but fails to activate Koenig
> // in the frontend even in "strict" mode, unless you use
> // -Qoption,cpp,--arg_dep_lookup. (reported by Kirk Klobe & Thomas
> // Similarly, -Qoption,cpp,--new_for_init enables new-style "for"
> // variable scoping. (reported by Thomas Witt)
> // Intel C++ 6.0 (currently in Beta test) doesn't have any
> // changes at all. (reported by Kirk Klobe)
> // That can't be right, since it supports template template
> // arguments (reported by Dave Abrahams)
># ifndef BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP
># define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP
># define BOOST_NO_SWPRINTF
>I have two questions about this:
>1. Is there a reason we're checking _MSC_VER here?
>2. Can we just eliminate the #define for
I came to the same conclusion before reading this post and have already
committed the change. Also changed the comment to better describe the
situation as regards BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP
>I ran the config tests for intel 5,6,7 and got the following
>interesting results, but I am at a loss to interpret them. Do the
>link errors with Intel7 mean that we failed to get the whchar_t
>support settings right?
I just did an intel-win32 clean and then limits_test. It compiled, linked,
and ran without error.
>What does it mean that intel5,6 still report
>BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP? I don't know what to do with
Because # define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is (or was, until I
removed it) hardwired into intel.hpp when used with msvc?
Be careful about making changes at this point. AFAICS, the
intel-win32-tools.jam and intel.hpp stuff is working far better than it
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk