Convert template argument to string

[Marco Nef]

Hi there

I'm looking for a template class that converts the template argument to a
string, so something like the following should work:

Convert<float>::Get() == "float";
Convert<3>::Get() == "3";
Convert<HelloWorld>::Get() == "HelloWorld";

The reason I need this is that in our design every class of a certain
hierarchy has a class name that must be unique. So far I could not find a
solution for template classes.

Thanks for your ideas
Marco

 

[Ian Collins]

Hi there

I'm looking for a template class that converts the template argument to
a string, so something like the following should work:

Convert<float>::Get() == "float";
Convert<3>::Get() == "3";
Convert<HelloWorld>::Get() == "HelloWorld";

The reason I need this is that in our design every class of a certain
hierarchy has a class name that must be unique. So far I could not find
a solution for template classes.

You have to provide one or use typeid.

 

[Marcel Müller]

I'm looking for a template class that converts the template argument to
a string, so something like the following should work:

Convert<float>::Get() == "float";
Convert<3>::Get() == "3";
Convert<HelloWorld>::Get() == "HelloWorld";

The reason I need this is that in our design every class of a certain
hierarchy has a class name that must be unique. So far I could not find
a solution for template classes.

Solution 1:

Use RTTI. With typeid(...).name() you will get a unique name. However,
this name is compiler dependant and may not look pretty at all. If you
don't care about that, it is fine. (Of course, the lookup is done at
runtime.)


Solution 2:

The good old macros.
#define TOSTRING(x) #x
will convert anything you pass to it into a string, e.g. TOSTRING(float)
will evaluate to "float" at compile time. But you will not manage to
take care of namespaces this way. The macro will always return the
string as it is - with or w/o namespace prefix.


Marcel

 

[Maxim Yegorushkin]

I'm looking for a template class that converts the template argument to a
string, so something like the following should work:

Convert<float>::Get() == "float";
Convert<3>::Get() == "3";
Convert<HelloWorld>::Get() == "HelloWorld";

The reason I need this is that in our design every class of a certain
hierarchy has a class name that must be unique. So far I could not find a
solution for template classes.

What do you need those names for? Why do you want for it to work with
values as well as with types?

If typeid(X).name() is not sufficient for you (not portable, may be
not human readable), you'll have to provide a string for every class
yourself.

 

[Marco Nef]

I'm looking for a template class that converts the template argument to

What do you need those names for? Why do you want for it to work with
values as well as with types?

If typeid(X).name() is not sufficient for you (not portable, may be
not human readable), you'll have to provide a string for every class
yourself.

Thanks for your replies. I know about typeid and it is not sufficient as
"typeid->name" by the standard is not persistent and not even unique. The
macro "TOSTRING(x) #x" does not work because it is evaluated before the
template process works. This means that "Convert<float>::Get()" returns
"Type" if Type is the name of the template argument.

Another solution would be the following:

template<typename Type> struct Convert
{
const String &GetName(VOID) const { return Type::GetName(); }
};
template<> struct Convert<float>
{
const String &GetName(VOID) const { return "float"; }
};
template<> struct Convert<int>
{
const String &GetName(VOID) const { return "int"; }
};

and so on...

So any classes provided as template argument need to implement GetName(),
for the base types there are specializations. This works, but I don't really
like it.

I would love a struct like:

template<typename Type> struct Convert
{
const String &GetName(VOID) const { return XXXXXX; }
};

where XXXXXX is the question of this task

Marco

 

[Maxim Yegorushkin]

Thanks for your replies. I know about typeid and it is not sufficient as
"typeid->name" by the standard is not persistent and not even unique. The
macro "TOSTRING(x) #x" does not work because it is evaluated before the
template process works. This means that "Convert<float>::Get()" returns
"Type" if Type is the name of the template argument.

Another solution would be the following:

template<typename Type> struct Convert
{
    const String &GetName(VOID) const { return Type::GetName(); }};

template<> struct Convert<float>
{
    const String &GetName(VOID) const { return "float"; }};

template<> struct Convert<int>
{
    const String &GetName(VOID) const { return "int"; }

};

and so on...

Please note, that in C++ you don't need (void) for functions with no
arguments. () is sufficient.

These GetName() functions return a reference to a non-existent
constant String, which is a programming error.

So any classes provided as template argument need to implement GetName(),
for the base types there are specializations. This works, but I don't really
like it.

You don't really need to provide a name for each specialisation,
because it can be generated in a generic fashion. Here is an example:

#include <string>
#include <iostream>

template<class T>
struct TypeName
{
static std::string get() { return T::typeName(); }
};

// add more specialisations for the build-in types
template<> std::string TypeName<int>::get() { return "int"; }

struct A
{
static std::string typeName() { return "A"; }
};

template<class T>
struct B
{
static std::string typeName() { return "B<" +
TypeName<T>::get() + ">"; }
};

int main()
{
std::cout << TypeName<int>::get() << '\n';
std::cout << TypeName<A>::get() << '\n';
std::cout << TypeName<B<int> >::get() << '\n';
std::cout << TypeName<B<A> >::get() << '\n';
std::cout << TypeName<B<B<B<int> > > >::get() << '\n';
}

Output:

int
A
B<int>
B<A>
B<B<B<int>>>

 

[James Kanze]

Marco Nef schrieb:

Solution 1:

Use RTTI. With typeid(...).name() you will get a unique name.

Maybe. I've never found a compiler where the name was
guaranteed unique, or was even unique in practice. If he's
using it in a template, however, it might be alright; templates
arguments must have external linkage, and most compilers do seem
to generate unique names for all types with external linkage.

Solution 2:

The good old macros.
#define TOSTRING(x) #x
will convert anything you pass to it into a string, e.g.
TOSTRING(float) will evaluate to "float" at compile time. But
you will not manage to take care of namespaces this way. The
macro will always return the string as it is - with or w/o
namespace prefix.

And within a template, TOSTRING(T) will result in "T",
regardless of what T actually means in the instantiation.

 

[James Kanze]

Thanks for your replies. I know about typeid and it is not
sufficient as "typeid->name" by the standard is not persistent
and not even unique.

What do you mean by "persistent" in this case?

And in practice, if the types are restricted to those you can
actually use to instantiate a template, about the only case
where they might not be unique in practice is if the types are
defined in anonymous namespace.

Another solution would be the following:

template<typename Type> struct Convert
{
const String &GetName(VOID) const { return Type::GetName(); }
};

template<> struct Convert<float>
{
const String &GetName(VOID) const { return "float"; }
};

template<> struct Convert<int>
{
const String &GetName(VOID) const { return "int"; }
};

and so on...

So any classes provided as template argument need to implement
GetName(), for the base types there are specializations. This
works, but I don't really like it.

Which is understandable. (Although you could use a macro to
generate the specializations.)

I would love a struct like:

template<typename Type> struct Convert
{
const String &GetName(VOID) const { return XXXXXX; }
};

where XXXXXX is the question of this task

The only thing anywhere like this in the standard is
typeid<Type>.name().

 

[Marco Nef]

Thanks for your replies. I know about typeid and it is not

What do you mean by "persistent" in this case?

My source for that is the book "Modern C++ Design" by Andrei Alexandrescu,
p. 206: "The way type_info::name is defined makes it unsuitable for anything
other than debuggin purposes. There is no guarantee that the string is the
actual class name, and worse, there is no guarantee that the string is
unique throughout the application."
....
"There is no guarantee that typeid(Line).name() points to the same string
when the application is run twice."

 

[James Kanze]

My source for that is the book "Modern C++ Design" by Andrei
Alexandrescu, p. 206: "The way type_info::name is defined
makes it unsuitable for anything other than debuggin purposes.
There is no guarantee that the string is the actual class
name, and worse, there is no guarantee that the string is
unique throughout the application."
...
"There is no guarantee that typeid(Line).name() points to the
same string when the application is run twice."

Aha. You mean that you can't use it as a type identifier in
persistent data.

The standard says that the string is implementation defined, and
in fact, an implementation which always returned "" would be
conforming. On the other hand, there are expectations due to
quality of implementation, which no compiler would dare neglect;
at the very least, you can certainly count on the string being
the same every time the function is called for the same type,
even in different runs, at least for non-local types (as long as
you haven't recompiled with a different compiler---or a
different version of the same compiler), and on the string being
different for classes with different basic names. In practice,
as long as the class isn't local or in an anonymous namespace, I
think you're OK.

Which, admittedly isn't very much, and I generally wouldn't use
it as a type identifier in external data (transmission protocols
or persistent data).