Using dmc 8.49.1 (latest patch over latest release).
This small program compiles:

------------
namespace a
{
   typedef int aa;
}

template<typename T>
::a::aa foo() { return 0; }

int main() {    return 0; }
------------------




Almost the same program (just returning const)
doesn't compile:

---------------------------
namespace a
{
   typedef int aa;
}

template<typename T>
const ::a::aa foo() { return 0; } //<<<=== here the leading :: fail

int main() {    return 0; }
------------------

with error:

Digital Mars C/C++ 8.49.1
int
  ^
x.cpp(13) : Error: malformed template declaration
--- errorlevel 1





When the leading :: before namespace is removed
the program compiles again:

---------------------------
namespace a
{
   typedef int aa;
}

template<typename T>
const a::aa foo() { return 0; } //<<<=== without leading :: it works

int main() {    return 0; }
------------------

The same problem had happened within much more
complex statement and was drilled down to this
example.


/Pavel


PS: I am playing with Boost and it looks
that DMC is able to compile practically all the code
(with STLport 5.10 and few fixes here and there).

What may be also bug is failure to compile template function like:


template<...>
typename complicated-return-type foo() { ... }

DMC doesn't like the word "typename".
The test case is in Boost.Multi-Index, a very
complicated expression.
I'll try to reduce it to something small.

/Pavel

This short source doesn't compile (8.49.1):

---------------------
template<typename T>
struct A
{
  typedef int a;
};

template<typename T>
struct B
{
  typedef A<T> c;
  typedef c::a a;
};

template<typename T>
void foo(B<T>::c::a* p) {}  // <<<=== here it fails

int main() {   return 0; }
-----------------

The problem is that DMC is not able
to recognize that "B<T>::c::a"
is valid nested typedef.

Replacing it with "B<T>::a"
(the same type but defined in B)
works. Adding "typename" in front
has no effect.

This is drilled down problem from
Boost.Filesystem.

/Pavel

Thanks for tracking these down.

The code:

--------------
#include <stdio.h>

struct A
{

static void foo()
{
   const char* s = __PRETTY_FUNCTION__;   // <<<=== here it fails
   printf("%s\n", s);
}

};

int main()
{
    A::foo();
    return 0;
}
------------

fails to compile because of use of __PRETTY_FUNCTION__. When the foo() is standalone or __FUNCTION__ is used everything is OK.


It looks that the __PRETTY_FUNCTION__ appends
semicolon. The statement:

const char* s = (const char*)__PRETTY_FUNCTION__ // no semicolon

compiles but produces some garbage.

/Pavel

This code doesn't compile with 8.49.1. It does with
Intel 9.0 and online Comeau.


------------------
// Loki's type select
template <bool flag, typename T, typename U>
struct Select
{
    typedef T Result;
};
template <typename T, typename U>
struct Select<false, T, U>
{
    typedef U Result;
};


struct A
{
    struct X {};
};


struct B
{
  struct X  {};

};

struct C : Select<true, A, B>::Result
{
    static void foo(X) {} //<<<=== here this fails
};

int main() { return 0; }
-----------------

The issue is with nested type X - it is not properly visible in derived class C and the foo() cannot use it.

The example is simplified form of Boost.MPL heavy code within Boost.Multi-Index.

/Pavel

This snippet doesn't compile:

--------------
struct nil_t {};

template <typename T = nil_t>
struct X;

template <>
struct X<nil_t>
{
    X();

    template <typename T>
    X<>& operator=(X<T> const& other) {
        return *this;
    }
};

inline X<nil_t>::X()
{}


int main() {   return 0; }
--------------------

I do not know what is moral story here,
but it is a most trimmed down problem
that occures in one of Boost.Spirit files.

Intel C++ 9.0 and Comean online do compile it.

/Pavel

I just got info that Boost will use the latest
DMC and STLport for regression tests available on
http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/user/

Before 8.44b and 4.5.3 were used with results
looking rather bad.

The change should be visible within 24 hours.

/Pavel

Pavel Vozenilek wrote:
> I just got info that Boost will use the latest
> DMC and STLport for regression tests available on
> http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/user/
> 
> Before 8.44b and 4.5.3 were used with results
> looking rather bad.
> 
> The change should be visible within 24 hours.
> 
> /Pavel
> 
> 

How are we looking now?

"Walter Bright" wrote:

>> I just got info that Boost will use the latest
>> DMC and STLport for regression tests available on
>> http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/user/
>>
>> Before 8.44b and 4.5.3 were used with results
>> looking rather bad.
>>
>> The change should be visible within 24 hours.
>>
>
> How are we looking now?
>

Not yet there. I'll try to run the test suite
on my machine. It should be faster and more
reliable than depending on who knows whom.
/Pavel