|
Boost : |
From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-07-11 07:24:27
On Wednesday 11 July 2001 07:08, you wrote:
> For some reason my code to test whether
> BOOST_NO_DEPENDENT_NESTED_DERIVATIONS is required or not fails with VC6,
> even though function_test.cpp (which uses the same constructs) builds fine
> when BOOST_NO_DEPENDENT_NESTED_DERIVATIONS is not defined.
>
> So, either the test case too strict, or is there something capricious going
> on. Anyone (particularly Doug) have any insights?
>
> I've attached the test code so you can try for yourself.
>
> - John Maddock
> http://ourworld.compuserve.com/homepages/john_maddock/
The testcase doesn't exactly match the construct used, and the difference is
enough to make MSVC work in some cases.
The first construct I noticed was this:
typedef typename foo<T>::template bar<UDT2> bar_type;
MSVC misparses this construct (it wants to find "bar" at namespace scope,
instead of delaying the lookup until foo<T> is instantiated), so it won't
pass the testcase. There is another problem, however.
The testcase vs. function_test.cpp differences essentially come down to:
// #1 Testcase (MSVC fails):
template<typename T> struct foo {
template<typename U> struct bar : public T, public U {};
};
// #2 Boost.Function uses (MSVC passes):
template<typename T> struct foo {
template<typename U> struct bar : public foo<U> {};
};
// #3 This also works for MSVC:
template<typename T> struct other {};
template<typename T> struct foo {
template<typename U> struct bar : public other<U> {};
};
I think it is the same MSVC bug as in the above ::template misparsing. MSVC
insists on finding a type (i.e. foo<U> or other<U>) but isn't satisfied by
finding a template type parameter, so it crashes. For reference, Borland
fails all of these testcases.
I would suggest using #3 as the test, but not doing it from a template
function so that you don't trigger the ::template bug. Just use:
typedef foo<UDT1>::bar<UDT2> bar_type;
Doug
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk