C++Talk.NET

Chris · Guest

Hi,

In the Loki library, macros are used as a shorthand for creating
Typelists [1]. The most recent issue of C/C++ Users Journal offers a
"template chain" alternative to the Loki shorthand [2]. In implementing
this solution, I came across some portability problems between g++ and
xlC. Consider this code fragment:

-- 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<cha r*> 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<cha r*> y; // I won't compile on xlC!

Foo<int>::This::Bar<double>::T his::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<cha r*> y; // I won't compile on xlC
Foo<int>::Bar<double>::This::B ar<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

[1] Modern C++ Design, Andrei Alexandrescu, Addison Wesley, 2002.
[2] "Using Chains to Free Library Code," C/C++ Users Journal, July
2005, p 26-29.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Graeme Prentice · Guest

On 15 Jun 2005 06:23:46 -0400, Chris wrote:

Graeme Prentice · Guest

On 18 Jun 2005 05:22:52 -0400, Graeme Prentice wrote:

Chris Hoge · Guest

Hi Graeme,

Thanks for the Comeau link. I've seen advertisements for it in the
regular magazines, but the tryitout link is pretty neat. I managed to
incorporate the typelist chain into the system I'm developing, and it
compiles on g++, xlC (the ibm/absoft compiler) and icpc (the intel
compiler). It works fairly well outside of a class scope. For example:
-- begin listing --

struct A : public MossBase< double, 10 > {};

struct B : public MossBase< SomeClass, 20 > {};
struct C : public MossBase< int, 1 > {};

typedef GenClass
<
typename TypeListGen::Y::

Add< A >::Y::
Add< B >::Y::
Add< C >::Y::
TypeList