www.digitalmars.com         C & C++   DMDScript  

c++ - [8.49.1 bug] leading :: before namespace

reply "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> writes:
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).
Jun 21 2006
next sibling parent "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> writes:
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
Jun 21 2006
prev sibling next sibling parent "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> writes:
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
Jun 22 2006
prev sibling next sibling parent Walter Bright <newshound digitalmars.com> writes:
Thanks for tracking these down.
Jun 22 2006
prev sibling next sibling parent "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> writes:
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
Jun 22 2006
prev sibling next sibling parent "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> writes:
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
Jun 22 2006
prev sibling next sibling parent "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> writes:
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
Jun 22 2006
prev sibling next sibling parent reply "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> writes:
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
Jun 23 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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?
Jun 23 2006
parent "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> writes:
"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
Jun 24 2006
prev sibling parent "Pavel Vozenilek" <pavel_vozenilek yahoo.co.uk> writes:
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
Jun 24 2006