Very Computer

I'm porting an application using the STL from Windows to RedHat Linux
v8.0 with GCC v3.2. I am attempting to use the STL map but am
encountering warnings that I did not encounter with Visual C++.

The pertinent aspects of the code looks something as follows:

#include <map>

template <class Idx_t, class Pld_t> class CDatabase {
public:
        std::map<Idx_t, Pld_t> m_DB;
        std::map<Idx_t, Pld_t>::iterator m_IT;

Quote:}

The warning I'm getting occurs when trying to create my variable for
the iterator:

database.h:104: warning: `typename std::map<Idx_t, Pld_t,
std::less<_Key>,
   std::allocator<std::pair<const _Key, _Tp> > >::iterator' is
implicitly a
   typename
database.h:104: warning: implicit typename is deprecated, please see
the
   documentation for details

I've used iterators like this quite a bit with Visual C++ but then
that's not saying much... What's different with GCC that it doesn't
like this method of accessing the iterator and what would be the
correct method?

Thanks in advance.

Randy Beckwith

Randy Beckwith escribi:

Quote:> template <class Idx_t, class Pld_t> class CDatabase {
> public:
>         std::map<Idx_t, Pld_t> m_DB;
>         std::map<Idx_t, Pld_t>::iterator m_IT;

Must be: typename std::map<Idx_t, Pld_t>::iterator m_IT;

Quote:> database.h:104: warning: implicit typename is deprecated, please see

The message is clear, implict typename is deprecated, then you need to
put it explicty.

Regards.

Is there an easy way to know beforehand where you have to put
'typename', so that all standard compliant compilers will compile the
code without warning?

Moritz

--
Dipl.-Phys. Moritz Franosch
http://Franosch.org

Whenever you use a type defined in a class template. So the map itself does
not need it, but the ::iterator in the map does.

Andre'

--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

Thank you. Yes, that's an easy rule and g++ should implement it. But
it does not. Please look at the following program:

template<typename T>
class A {
  typename T::subtype i;
  // "syntax error before `;' token" without 'typename' (1)

Quote:};

template<typename T>
class B {
public:
  typedef T elementtype;

Quote:};

class C {
  B<int>::elementtype e; // no warning here (2)

Quote:};

template<typename T>
class D {
  B<T>::elementtype e; // warning about implicit typename here (3)
  B<int>::elementtype e2; // no warning here (4)

Quote:};

int main() {

Quote:}

I've compiled with 'g++ -pedantic -Wall typename.cpp', g++ 3.2.0.

According to the rule g++ should give (at least) a warning in all
cases (1)-(4). But it does not warn in cases (2) and (3). Is this a
g++ bug?

Or does the rule only hold for a type such as B<T> where T is a
template parameter of the surrounding class C declared before by
'template<typename T> class C ...'?

The documentation of g++ 3.2.0 says:

   The implicit typename extension has been deprecated and will be
   removed from g++ at some point.  In some cases g++ determines that
   a dependant type such as `TPL<T>::X' is a type without needing a
   `typename' keyword, contrary to the standard.

I think in case (1) g++ can not determine whether T::subtype is a
(static) member of T or a type (no one can, depends on T).

Whereas in case (3) g++ is so smart to look at the template definition
of B and determines that B<T>::elementtype is a type, whatever T may
be.

In cases (2) and (4) every standard compliant compiler should be able
to figure out that B<int>::subtype is a type by instantiating
template<typename T> class B. (?)

Moritz

--
Dipl.-Phys. Moritz Franosch
http://Franosch.org

You wanted to know an easy way. The other one would be (quoting from CD2)

  A name used in a template is assumed not to name  a  type  unless  the
  applicable  name  lookup finds a type name or the name is qualified by
  the keyword typename.

The rules for name lookup are a bit ... erm ... tricky.

Quote:> According to the rule g++ should give (at least) a warning in all
> cases (1)-(4). But it does not warn in cases (2) and (3). Is this a
> g++ bug?

No, just my rule of thumb that's buggy.

Andre'

--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

The actual type of i depends on the template parameter T of the class
template A. typename is necessary. See case 3. The error message is not
nice.

Quote:

> template<typename T>
> class B {
> public:
>   typedef T elementtype;
> };

> class C {
>   B<int>::elementtype e; // no warning here (2)
> };

No warning needed, since B<int> is an actual type, i.e. a template that is
instantiated at the crucial point.

Quote:

> template<typename T>
> class D {
>   B<T>::elementtype e; // warning about implicit typename here (3)

B<int>::elementtype could be a type, but B<double>::elementtype could be
something completely different, e.g. a static member. Here the typename is
necessary, the actual type depends on the template parameters of the
template you are about defining.

Quote:>   B<int>::elementtype e2; // no warning here (4)

Again, B<int> is a known type.

Quote:

> Or does the rule only hold for a type such as B<T> where T is a
> template parameter of the surrounding class C declared before by
> 'template<typename T> class C ...'?

This is the rule I use. IOW typename is only necessary if you are in a
template AND a thing you are referring to as a type depends on the current
template parameters.

I think that typename stuff is mainly a parser problem. Since a new parser
is on the way in g++, perhaps for 3.4?, I think there will be improvements
in this area as well. Case (1) from above is clearly a suboptimal
diagnostic.

Bernd Strieder

Yes, I thought so.

Quote:> > According to the rule g++ should give (at least) a warning in all
> > cases (1)-(4). But it does not warn in cases (2) and (3). Is this a
> > g++ bug?

> No, just my rule of thumb that's buggy.

But if you compile with g++ 3.2 -pedantic and fix all the warnings,
all 'typenames' should be ok (or even too many typenames, which does
not do any harm).

Thank you again,

Moritz

Yes, I've got the information that a parser bug I've reported will be
fixed due to the new parser in 3.4. (This was no bug actually, but a
g++ extension. With -pedantic, g++ was correct. The extension will be
dropped in the new parser.)

Quote:> I think there will be improvements in this area as well. Case (1)
> from above is clearly a suboptimal diagnostic.

Yes. But I've already got used to the fact that "syntax error before
&/;" in g++ most often translates to "undefined type before &/;".

Only sometimes you don't know which & the compiler means. Intel C++ is
nicer here. It points with ^ to the exact place where the problem is.

Moritz

--
Dipl.-Phys. Moritz Franosch
http://Franosch.org