S
Shane
(reposted from comp.sys.hp.hpux)
The following code compiles fine on A5.52 and other compilers, however aCC
6.15 generates an error:
#include <vector>
using namespace std;
class ClassA : public vector<ClassA, allocator<ClassA> >
{
public:
ClassA() : vector<ClassA, allocator<ClassA> >() {}
};
compiled produces the error:
"test.cc", line 9: error #2265-D: type
"std::allocator<_TypeT>::allocator [with _TypeT=ClassA]" (declared
at line 240 of "/opt/aCC/include_std/memory") is inaccessible
ClassA() : vector<ClassA, allocator<ClassA> >() {}
Qualifying 'allocator' with 'std::' fixes the error:
#include <vector>
using namespace std;
class ClassA : public vector<ClassA, allocator<ClassA> >
{
public:
ClassA() : vector<ClassA, std::allocator<ClassA> >() {}
};
When using a custom allocator in the global namespace, the error is still
there, and '::' must be used instead. Alternatively the type can be
typedefed.
The error is listed twice here as a compatability issue:
http://h21007.www2.hp.com/portal/si...ciid=2708d7c682f02110d7c682f02110275d6e10RCRD
However the above code only uses public inheritence so I'm not sure it
applies. Is this a regression in this release, or are the above changes
required?
The following code compiles fine on A5.52 and other compilers, however aCC
6.15 generates an error:
#include <vector>
using namespace std;
class ClassA : public vector<ClassA, allocator<ClassA> >
{
public:
ClassA() : vector<ClassA, allocator<ClassA> >() {}
};
compiled produces the error:
"test.cc", line 9: error #2265-D: type
"std::allocator<_TypeT>::allocator [with _TypeT=ClassA]" (declared
at line 240 of "/opt/aCC/include_std/memory") is inaccessible
ClassA() : vector<ClassA, allocator<ClassA> >() {}
Qualifying 'allocator' with 'std::' fixes the error:
#include <vector>
using namespace std;
class ClassA : public vector<ClassA, allocator<ClassA> >
{
public:
ClassA() : vector<ClassA, std::allocator<ClassA> >() {}
};
When using a custom allocator in the global namespace, the error is still
there, and '::' must be used instead. Alternatively the type can be
typedefed.
The error is listed twice here as a compatability issue:
http://h21007.www2.hp.com/portal/si...ciid=2708d7c682f02110d7c682f02110275d6e10RCRD
However the above code only uses public inheritence so I'm not sure it
applies. Is this a regression in this release, or are the above changes
required?