Conference turris::c_plus_plus

/*
The behaviour you are seeing has nothing to
do with namespaces. Namespaces are not used
in the V5.6 version of the standard library.

The code is illegal and is now correctly diagnosed in
V5.6. There's a class variable called map and so if
you want to refer to the global map when you're inside 
the class scope you have to use :: to distinguish it.

So the user either needs to change the name of the
variable map or needs to change:

	typedef map<int, int, less<int>, allocator<pair <const int, int> > > 
				Map_String_String;

to:

	typedef ::map<int, int, less<int>, allocator<pair <const int, int> > > 
				Map_String_String;

Below is a small example showing the situation. 

FYI, if you make map a non-templatized class then you'll see
that V5.5 used to complain in that situation.
*/

// This was not diagnosed in V5.5, it is diagnosed in V5.6
template <class T>
class map {};

struct MyClass {
	typedef map<int> foo; // oops, need to put :: to refer to global  
	int map;
};

Hi J.,

The customer cames back with the further problem: when it uses the so defined
type (Map_String_String), it get another error:

map1.cc:
========
#include <map>
class MyClass
{
    public:
        typedef int             MyType;
        typedef ::map<int, int, less<int>, allocator<pair <const int, int> > >
                                Map_String_String;
    private:
        MyType                  myAttribute;
        Map_String_String       map;

        void f(void){
                Map_String_String::const_iterator i = map.find(2);
        };
};

$ cxx -c map1.cc
cxx: Error: map1.cc, line 17: Declaration has no type or storage class.
                Map_String_String::const_iterator i = map.find(2);
----------------^

On another hand, the below code will compile:

map2.cc:
========
#include <map>
class MyClass
{
    public:
        typedef int             MyType;
        typedef ::map<int, int, less<int>, allocator<pair <const int, int> > >
                                Map_String_String;
    private:
        MyType                  myAttribute;
        Map_String_String       map;

        void f(void){
                ::map<int, int, less<int>, allocator<pair <const int, int> >
>::const_iterator i = map.find(2);
        };
};

The correction in .1 would have been a simple correctio, but implementing map2
... You can imagine ?!.

Best,
Mich�le.

I think what you (they?) are seeing is
a compiler bug. It works correctly in our
6.0 (under development) compiler.

I will post it in our internal bug tracking
system. Below is a small example showing
the bug and also a possible workaround.

// This is a small example showing a 
// bug with scoping and typedefs
// I think this should compile cleanly

struct map {
	typedef int itype;
};

struct MyClass
{
        typedef ::map map_type;
        void f() { map_type::itype i;}
};

main() {;}

// The only workaround I can think of is to create a typedef
// inside MyClass corresponding to each typedef in map that 
// they are using, i.e.:

#include <map>

class MyClass
{
    public:
        typedef int             MyType;
        typedef ::map<int, int, less<int>, allocator<pair <const int, int> > >
                                Map_String_String;

	// add this for each typedef you need
        typedef ::map<int, int, less<int>, allocator<pair <const int, int> >
>::const_iterator
                                Map_String_String_const_iterator;

    private:
        MyType                  myAttribute;
        Map_String_String       map;

        void f(void){
		// change this
                Map_String_String_const_iterator i = map.find(2);
        };
};

Judy

I just forward your input to the customer that I receive some new hints about
the problem. I'm not sure he had read your answer but the workaround he found
may help you. Or be completely wrong (he'snot using the ::map syntax anymore).

So I add his inputs here.

    � Some more information about the problem reported with the reproducer.  �
    � The following shows that the problem disappears when avoiding the use  �
    � of template default values as in this reworked version:                �


[[ map4.cc : 3669 in map4.cc ]]

#include <map> 
#include <iostream.h>

template <class Key, class T, class Compare, class Allocator>
ostream& operator<<(ostream& os, const map<Key,T,Compare, Allocator>& theMap);

class MyClass
{
  public:
    typedef	map<int, int, less<int>, allocator<pair <const int, int > > >
			Map_String_String; //GENB
  private:
    Map_String_String 	aMapWithTypeDef;
    map<int, int, less<int>, allocator<pair <const int, int > > > 
			aMapWithoutTypeDef; //GENB

    void f(ostream& os) {
	os << aMapWithoutTypeDef;
	os << aMapWithTypeDef;
    };
};

Since this is fixed in V6.0 and since this is no longer an
issue to the customer, we don't plan any further action
on this problem report.