Curious template behavior, g++ and xlC and icpc

C

ckhoge

Hi,

Consider this code fragment, based on the article "Using Chains to Free
Library Code" from the July 2005 issue of C/C++ Users Journal:

-- begin listing --
template <class T>
struct Foo
{
template <class S>
struct Bar : public Foo<S>
{
};
};

int main()
{
Foo<double>::Bar<int> x;
Foo<int>::Bar<double>::Bar<char*> y;

return 0;
}
-- end listing --

g++ and icpc compiles this bit of code without complaint. xlC, on the
other hand, has trouble with resolving the names and returns the error:

"test.cpp", line 14.39: 1540-0300 (S) The "private" member "struct
Foo<int>::Bar<char *>" cannot be accessed.

This leads me to the first question (since I'm not as well versed in
the standard as I would like): which compiler is to be believed? And a
second question: how can I write a portable version of that listing? I
took a stab at the second question and came up with:

-- begin listing --
template <class T>
struct Foo
{
typedef Foo<T> This;

template <class S>
struct Bar : public Foo<S>
{
};
};

int main()
{
Foo<double>::This::Bar<int> x;
Foo<double>::Bar<int> x_clone;

// A quick test to see if the types make sense
x = x_clone;

// Foo<int>::Bar<double>::Bar<char*> y; // I won't compile on xlC!
Foo<int>::This::Bar<double>::This::Bar<char*> y_clone;

// y = y_clone; // I won't compile on xlC!

return 0;
}
-- end listing --

At first glance, this seems to do the trick, but if we uncomment the "I
won't compile" lines, and try to compile them with g++ we get:

test.cpp: In function `int main()':
test.cpp:23: no match for `Foo<int>::Bar<char*>& =
Foo<double>::Bar<char*>&'
operator
test.cpp:9: candidates are: Foo<int>::Bar<char*>&
Foo<int>::Bar<char*>::eek:perator=(const Foo<int>::Bar<char*>&)

icpc gives a similar error. The types aren't matching up! The typedef
is looking at the top level for y, but at the inherited level for
y_clone. So what's a solution to this? Moving the typedef from the
parent class to the child class gives us:

-- begin listing --
template <class T>
struct Foo
{

template <class S>
struct Bar : public Foo<S>
{
typedef Foo<T> This;
};
};

int main()
{
Foo<double>::Bar<int> x;
Foo<double>::Bar<int> x_clone;

x = x_clone;

Foo<int>::Bar<double>::Bar<char*> y; // I won't compile on xlC
Foo<int>::Bar<double>::This::Bar<char*> y_clone;

y = y_clone; // I won't compile on xlC

return 0;
}
-- end listing --

We get the desired behavior with icpc and g++ (that is, the type
signatures match up), and xlC builds the program. Now, since building
is not a sign of correctness, I will state that the desired
funcionality (as described in the article) is obtained, at the expense
of the original goal of brevity. My inclination is to believe that the
xlC implementation of templates is broken. Anyone have thoughts or
comments?

Thanks,
Chris
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,007
Latest member
obedient dusk

Latest Threads

Top