Boost logo

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