Type of variable

[deepak]

Hi,

How can a find the type of a variable in a program?
Is there any way to do that?

Thanks,
Deepak

 

[dev1-002]

For primitive types? I don't think so.
If there are any way to do that, a structure should be competent to do
that kind of thing.

 

[dsriharsha]

Hi,

How can a find the type of a variable in a program?
Is there any way to do that?

Thanks,
Deepak

Look at the source code where the variable is declared.

Harsha

 

[Nick Keighley]

How can a find the type of a variable in a program?
Is there any way to do that?

no. Why would you want to do that?

 

[spinoza1111]

deepak said:



Your question is ambiguous. If you simply mean, "I'm looking at some
source code and I'd like to know the type of an identifier", then the
answer is "yes, read the relevant definition".

If you mean, "I'd like my program to be able to work out the types of
arbitrary identifiers", then the answer is a little more complicated.
The short answer is "no", and the slightly longer answer is "yes, if
you have access to the source code and are prepared to write a few
parts of a compiler" (which, in the vast majority of cases, is
another way of saying no).

Richard is right if the original poster is asking about C. Since this
is comp.lang.c, Richard is probably right.

But in C Sharp one can code mung.GetType().

And with reflection, common to Java and .Net, much much more.

 

[spinoza1111]

no. Why would you want to do that?

To verify that what you've been passed is not garbage.

 

[osmium]

:

(e-mail address removed)...

no. Why would you want to do that?

To verify that what you've been passed is not garbage.

There is an old saying, ask a stupid question, get a stupid answer. The
last two responses are a perfect example. The original post (which makes
perfect sense) is only retained to provide context.

 

[Tom St Denis]

To verify that what you've been passed is not garbage.

In a lot of cases you simply *can't* know that. Suppose I have a
function that does vector additions and I have

void vec_add(vec *a, vec *b, vec *c); // c = a + b

Where

typedef struct {
int x, y, z;
} vec;

Aside from checking for NULL, what else would you check for? What is
a "non-garbage" pointer?

About the only thing you could do is make sure that the pointers are
global, auto, or the return of calloc/malloc/realloc. You could wrap
calloc/malloc/realloc, but you can't really tell in a portable way if
it's part of a global or auto space.

Tom

 

[Eric Sosman]

no. Why would you want to do that?

Some languages support the manipulation of type information
at run-time, and this can be useful. You might, for example,
write a linear algebra package that supported vectors and matrices
of float, double, long double, _Complex, and so on, all with just
one version of the code. (In theory, anyhow. In practice, things
like convergence criteria often vary with the precision of the
type being used and will not "just work" with other types.)

However, C isn't such a language. Types are creatures of the
compiler, not of run-time.

 

[Antoninus Twink]

How can a find the type of a variable in a program? Is there any way
to do that?

Yes.

Many compilers, e.g. gcc, have a builtin called typeof or something
similar that will let you do this.

This is something that should obviously be in the ISO Standard just as
sizeof is, but for some reason it isn't.

 

[bartc]

Yes.

Many compilers, e.g. gcc, have a builtin called typeof or something
similar that will let you do this.

This is something that should obviously be in the ISO Standard just as
sizeof is, but for some reason it isn't.

typeof only seems to be usable in places where a regular type name could be
used, ie. in declarations and casts, so is probably of limited use for the
OP's purpose.

At least, I couldn't do this:

printf ("Type of x is: %d", typeof(x));

 

[spinoza1111]

     Some languages support the manipulation of type information
at run-time, and this can be useful.  You might, for example,
write a linear algebra package that supported vectors and matrices
of float, double, long double, _Complex, and so on, all with just
one version of the code.  (In theory, anyhow.  In practice, things
like convergence criteria often vary with the precision of the
type being used and will not "just work" with other types.)

In C Sharp, the "generic" facility allows you to do this while
avoiding having to check for types at runtime.

 

[spinoza1111]

In a lot of cases you simply *can't* know that.  Suppose I have a
function that does vector additions and I have

void vec_add(vec *a, vec *b, vec *c); // c = a + b

Where

typedef struct {
   int x, y, z;

} vec;

Aside from checking for NULL, what else would you check for?  What is
a "non-garbage" pointer?

About the only thing you could do is make sure that the pointers are
global, auto, or the return of calloc/malloc/realloc.  You could wrap
calloc/malloc/realloc, but you can't really tell in a portable way if
it's part of a global or auto space.

Tom

True. In C, you never know
Where the pointers go,
They point over here,
They point over there,
Those pointers point just everywhere
Do they point to heaven?
Or to hell?
Like the Scarlet Pimpernel,
They are damn'd elusive,
And nothing conclusive
Can be said
About many C programs which on arrival
Are dead.

 

[Peter 'Shaggy' Haywood]

Groovy hepcat
(e-mail address removed)-did-not-set--mail-host-address--so-tickle-me was
jivin' in comp.lang.c on Fri, 14 Aug 2009 5:46 pm. It's a cool scene!
Dig it.

For primitive types? I don't think so.
If there are any way to do that, a structure should be competent to do
that kind of thing.

What the hell are you talking about? I have not seen the rest of this
thread (yet), so I have no idea what you're referring to. What about
"primitive types" (whatever that means)? Any way to do what? Do what
kind of thing? What does all this mean?
In future, please quote (relevant portions of) the post to which you
are replying, including attributions, so we know what it's all about.
See how I have quoted you (the lines beginning with ">") and given due
attribution (the part beginning with "Groovy hepcat").

 

[Nick Keighley]

:
(e-mail address removed)...





To verify that what you've been passed is not garbage.

There is an old saying, ask a stupid question, get a stupid answer.  The
last two responses are a perfect example.  The original post (which makes
perfect sense) is only  retained to provide context.

unsurprisingly I disagree. There *is* no way to find type at runtime
in C. C++ has ways to do this. So do some other languages with
run-time type systems. C is statically typed so you can't do this.
The normal thing to is to do as much type checking at compile time
as possible. So I asked the OP why he wanted to do this, in the hope
of getting some insight into why he was doing this. This might
have led me to some suggestion as to how he avoid trying to
do the impossible. For instance void* + tag or union + tag or
use C's type system correctly.

etc. I fail to see how my question was dumb enough to encourage
your sarky answer.

 

[Nick Keighley]

Yes.

Many compilers, e.g. gcc, have a builtin called typeof or something
similar that will let you do this.

This is something that should obviously be in the ISO Standard just as
sizeof is, but for some reason it isn't.

I can't see how you can be unaware of the type of a variable
in normal C. There must be a declaration/definition in scope.
Unless gcc has added some sort of anonymous type

void print (ANON x)
{
switch (typeof(x))
{
case int:
printf ("%d", (int)x);
break;

...etc...
}
}

this seems to do some violence to the fundamentals of C

 

[Alan Curry]

I can't see how you can be unaware of the type of a variable
in normal C. There must be a declaration/definition in scope.

Normally, if you're using typeof, it'll be on an argument to a macro, to
enable the macro to work with arguments of varying types.

Unless gcc has added some sort of anonymous type

You could think of macro arguments as being anonymously typed, since the
preprocessor doesn't know types.

#define SWAP(a,b) do { typeof(a) tmp; tmp=a; a=b; b=tmp; } while(0)

int i, j;
float f, g;
char *s, *t;
void *p, *q;
struct { int d[100]; } v, w;
void foo(void)
{
SWAP(i,j);
SWAP(f,g);
SWAP(s,t);
SWAP(p,q);
SWAP(v,w);
}

void print (ANON x)
{
switch (typeof(x))
{
case int:
printf ("%d", (int)x);
break;

...etc...
}
}

this seems to do some violence to the fundamentals of C

Good thing gcc's typeof doesn't work anything like that. It's only legal
where an ordinary type keyword would be legal, and it can only do the things
that ordinary type keywords can do. If you wanted to define a macro with 2
arguments and have it do something depending on whether the 2 arguments have
the same type, you'd be out of luck.

int x;
long y;
#define SAMETYPE(a,b) (typeof(a)==typeof(b)) /* Broken */
if(SAMETYPE(x,y))
puts("Same")

That doesn't work, for the same reason if(int==long) doesn't work. Types
can't be compared. That would be a significant extra feature pretty much
independent of typeof(). switch(typeof(x)) is right out.

 

[Nick Keighley]

Normally, if you're using typeof, it'll be on an argument to a macro, to
enable the macro to work with arguments of varying types.

ok, so its more limited than I suggested. I figured it would have to
be or the language would no longer be C-like.

You could think of macro arguments as being anonymously typed, since the
preprocessor doesn't know types.

#define SWAP(a,b) do { typeof(a) tmp; tmp=a; a=b; b=tmp; } while(0)

even this implies some sort of back channel between the preprocessor
and the compiler. Since the preprocessor doesn't know the type
of "a" it can't simply stuff the type in place in a normal macro like
way. It looks like the maco doesn't get fully expanded until syntax
analysis
time.

Good thing gcc's typeof doesn't work anything like that. It's only legal
where an ordinary type keyword would be legal, and it can only do the things
that ordinary type keywords can do. If you wanted to define a macro with 2
arguments and have it do something depending on whether the 2 arguments have
the same type, you'd be out of luck.

int x;
long y;
#define SAMETYPE(a,b) (typeof(a)==typeof(b)) /* Broken */
if(SAMETYPE(x,y))
  puts("Same")

That doesn't work, for the same reason if(int==long) doesn't work. Types
can't be compared. That would be a significant extra feature pretty much
independent of typeof(). switch(typeof(x)) is right out.

interesting, but I suspect hard to implement on some existing systems.

 

[Alan Curry]

even this implies some sort of back channel between the preprocessor
and the compiler. Since the preprocessor doesn't know the type
of "a" it can't simply stuff the type in place in a normal macro like
way. It looks like the maco doesn't get fully expanded until syntax
analysis
time.

No, the preprocessor doesn't implement typeof() any more than it implements
sizeof(). It just happens to be most useful in type-generic macros.

When I say

int i, j;
SWAP(i,j);

the preprocessor's output is

int i, j;
do { typeof(i) tmp; tmp=i; i=j; j=tmp; } while(0);

Understanding that "typeof(i)" means "int" is not part of preprocessing.

To come up with a similar example with sizeof(), imagine a type-generic
copy operation for reading an arbitrary value from an unaligned location, and
putting it into a properly aligned object:

#include <string.h>
/* ptr must be a char * but var can be any type */
#define GET_UNALIGNED(ptr, var) do { \
memcpy(&var, ptr, sizeof(var)); \
ptr += sizeof(var); \
} while(0)

/* Data format: 1 char, then 1 short, then 1 int, then 1 double, no padding.
Need to make them aligned properly before working on them. */
int foo(char *data)
{
char *p = data;
char c;
short s;
int i;
double d;
GET_UNALIGNED(p, c);
GET_UNALIGNED(p, s);
GET_UNALIGNED(p, i);
GET_UNALIGNED(p, d);
return d+i+s+c;
}

The macro expansion isn't delayed until the sizeof() can be evaluated. It
expands sizeof(var) to sizeof(c), sizeof(s), sizeof(i), sizeof(d), and then
the compiler does the work of turning sizeof(c) into 1, sizeof(s) into (most
likely) 2, and so on. Perfect parallel to typeof() in the other example.

(Bonus irony: I test-compiled the above with gcc and it optimized the memcpy
calls into unaligned load instructions!)

 

[Nick Keighley]

No, the preprocessor doesn't implement typeof() any more than it implements
sizeof(). It just happens to be most useful in type-generic macros.

When I say

  int i, j;
  SWAP(i,j);

the preprocessor's output is

  int i, j;
  do { typeof(i) tmp; tmp=i; i=j; j=tmp; } while(0);

Understanding that "typeof(i)" means "int" is not part of preprocessing.

ah. Thanks. Failure of imagination on my part. It might even be
what the OP wanted. On the other hand it may not. Which is why I asked
the
why question...

<snip>