By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,865 Members | 1,725 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,865 IT Pros & Developers. It's quick & easy.

Curious template behavior, g++ and xlC and icpc

P: n/a
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*>::operator=(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

Jul 23 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.