Print name of typedef:ed type

[Eric Lilja]

Hello, in my c++ program I have the following "block":
#if defined __GNUC__ && defined NOT_PEDANTIC
typedef unsigned long long inttype;
#elif defined _MSC_VER
typedef unsigned __int64 inttype;
#else
typedef unsigned long inttype;
#endif

I'm wondering if there's a way, without resorting to the preprocessor,
to print the actual type (its name) of inttype when the program is
running? In the meantime I'm printing what
numeric_limits<inttype>::max() returns to give some hint.

- Eric

 

[Pete Becker]

Hello, in my c++ program I have the following "block":
#if defined __GNUC__ && defined NOT_PEDANTIC
typedef unsigned long long inttype;
#elif defined _MSC_VER
typedef unsigned __int64 inttype;
#else
typedef unsigned long inttype;
#endif

I'm wondering if there's a way, without resorting to the preprocessor,
to print the actual type (its name) of inttype when the program is
running? In the meantime I'm printing what
numeric_limits<inttype>::max() returns to give some hint.

Since you're already relying on the preprocessor, why do you object to
using it? Just add a string literal to each branch of your if ladder.

 

[Victor Bazarov]

Hello, in my c++ program I have the following "block":
#if defined __GNUC__ && defined NOT_PEDANTIC
typedef unsigned long long inttype;
#elif defined _MSC_VER
typedef unsigned __int64 inttype;
#else
typedef unsigned long inttype;
#endif

I'm wondering if there's a way, without resorting to the preprocessor,
to print the actual type (its name) of inttype when the program is
running? In the meantime I'm printing what
numeric_limits<inttype>::max() returns to give some hint.

First off, there is no "long long" (signed or not) in C++. There is
no __int64 in C++ either.

You could try using 'typeid(expression).name()' to get the string
that contains the implementation's best approximation to the type of
the expression. I tried it with VC++ v8, and it gives back the actual
type.

There is no clean way in C++ language itself, though, since the 'name'
member of 'std::typeinfo' is allowed to return an empty string.

V

 

[Eric Lilja]

First off, there is no "long long" (signed or not) in C++. There is
no __int64 in C++ either.

I know, that's why I'm using the preprocessor to activate compiler
extensions where available.

You could try using 'typeid(expression).name()' to get the string
that contains the implementation's best approximation to the type of
the expression. I tried it with VC++ v8, and it gives back the actual
type.

There is no clean way in C++ language itself, though, since the 'name'
member of 'std::typeinfo' is allowed to return an empty string.

I see, I will try it and see what happens on the other compilers I'm
targeting. VC++ v8 is one of them so at least I get the desired output
under that compiler it seems.

- Eric

 

[Eric Lilja]

Since you're already relying on the preprocessor, why do you object to
using it? Just add a string literal to each branch of your if ladder.

Ah, good idea, I didn't think of that. I was trying to avoid using the
preprocessor again around the cout-statements and with your solution I
will avoid having to do just that. But I will try Victor's suggestion
as well just to see what happens. Thanks for your help and your quick
replies!

- Eric

 

[James Kanze]

First off, there is no "long long" (signed or not) in C++.
There is no __int64 in C++ either.

There's neither of them in *standard* C++, but since long long
is part of C90, and will be part of the next version of C++,
it's pretty much universal today, and can be considered "C++"
(but you'll need -Wno-long-long to get it with g++).

You could try using 'typeid(expression).name()' to get the
string that contains the implementation's best approximation
to the type of the expression. I tried it with VC++ v8, and
it gives back the actual type.

VC++ tries to do something useful with it. So does Sun CC.
G++, on the other hand, returns the string it uses when mangling
names, which is usually pretty useless. (For a long long, I get
"x".)

There is no clean way in C++ language itself, though, since
the 'name' member of 'std::typeinfo' is allowed to return an
empty string.

Or gibberish. Some compilers have decided that gibberish is the
way to go.

 

[Victor Bazarov]

VC++ tries to do something useful with it. So does Sun CC.
G++, on the other hand, returns the string it uses when mangling
names, which is usually pretty useless. (For a long long, I get
"x".)


Or gibberish. Some compilers have decided that gibberish is the
way to go.

I believe the point is that it's the same gibberish every time for
the same type. Furthermore, if it's "x" for 'long long', then it
is going to be "x" for a typedefed synonym of 'long long'. That's
*relatively* useful.

V

 

[James Kanze]

I believe the point is that it's the same gibberish every time
for the same type. Furthermore, if it's "x" for 'long long',
then it is going to be "x" for a typedefed synonym of 'long
long'. That's *relatively* useful.

OK, I see your point. The standard doesn't make any guarantees,
of course---all it says is that the function returns an
implementation defined '\0' string. So presumably, any random
value would do. In practice, however, I've yet to see a
compiler which returned a different string at different times
for the same type (and of course, typedef does not create a new
type), and most compilers will usually return different strings
for different types---all I've seen will return different
strings for all of the built-in types, and for all user defined
types defined at namespace (and class?) scope (except maybe for
anonymous namespace scope). Start defining local classes, or
defining classes in anonymous namespace, and all bets are off.
(This is probably the motivation for g++'s gibberish. By
outputting gibberish, you may not be able to easily read the
name, but it's easy for them to guarantee that all of the names
are unique. Generating something that's readable in the general
case, but guaranteed unique always, is hard work, and as far as
I know, no implementor has bothered to do it.)

And to retouch on the original point: since it's implementation
defined, it must be documented for an implementation to be
conform. Good luck in finding the documentation, however.

 

[Joel Yliluoma]

I know, that's why I'm using the preprocessor to activate compiler
extensions where available.

You could use int_least64_t and/or int_fast64_t from cstdint.