• "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> Jun 21 2006
• "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> Jun 21 2006
• "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> Jun 22 2006
• Walter Bright <newshound digitalmars.com> Jun 22 2006
• "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> Jun 22 2006
• "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> Jun 22 2006
• "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> Jun 22 2006
• "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> Jun 23 2006
• Walter Bright <newshound digitalmars.com> Jun 23 2006
• "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> Jun 24 2006
• "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> Jun 24 2006

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

From a post in c.l.c++.m:

This doesn't compile whether or not
the WORKAROUND is defined.

----------------
// different compiler require or do not require the macro
//#define WORKAROUND

namespace na
{
class ca;

namespace nb
{
class cb {
#ifdef WORKAROUND
   friend class na::ca;
#else
   friend class ca;
#endif
   cb() {}
};

} // nb

class ca
{
  nb::cb b;
};

} // na

int main() {
   na::ca a;
  return 0;
}
---------------------

The example comes from someone's work
on Boost port under BCB 2006.
Different compilers require or do not require
the workaround, DMC fails always.

/Pavel